0

I am currently building a ChangeLog-generator, which is creating such a log by diff'ing the revisions of /trunk against /branch/... (which was created at some point from /trunk), to see which commits are not in the branch (and then does some fancy Redmine queries).

To minimize the log-range I wanted to optimize the query based on the revision used to create the branch as my offset.

I know the Stop on copy/rename feature of TortoiseSVN, to determine the revision used to create a specific branch or tag.

How can I achieve this with SharpSvn - or is there an easier way to determine the difference (to simplify the request: I will only diff /trunk against a descending branch ...).

2 Answers2

1

I got this to work with the following code - yet I am unsure if this is the most elegant way to do so:

var svnClient = new SvnClient();
svnClient.GetLog(new Uri("http://..../REPOSITORY/BRANCH/FOO",
                 new SvnLogArgs
                 {
                   StrictNodeHistory = true
                 },
                 out logItems);
var initRevision = logItems.OrderBy(arg => arg.Revision)
                           .First();
var changedPath = initRevision.ChangedPaths.Single();
//changedPath.CopyFromRevision
//changedPath.CopyFromPath

The thing that bugs me, is that I have to get the whole log, then order it accordingly to get the initial revision, which is used to retrieve the CopyFromRevision and CopyFromPath properties.

  • 1
    In general this approach should work... but if somebody creates a branch or tag and in the same commit also modifies something inside (or creates another branch) the .Single() approach doesn't work. I would recommend obtaining the actual path. You can improve the performance quite a bit by providing both a revision range (0:HEAD) and a limit (1) on the args object. – Bert Huijben Jan 08 '16 at 10:55
  • *I would recommend obtaining the actual path.* Can you show me how excatly? –  Jan 08 '16 at 13:44
0

If you keep your branches relatively related you might be able to use some of the mergeinfo helpers of Subversion to do most of the heavy lifting of determining what is on one branch and not on the other.

But if you use strict project policies doing things yourself might be much easier than that. Subversion tries to solve things in a 100% generic way, which may or may not match your requirements.

Bert Huijben
  • 19,525
  • 4
  • 57
  • 73
  • Could you please elaborate on the *mergeinfo helpers of Subversion* part a bit - I am curious! –  Jan 08 '16 at 13:43