Creating a subversion "tag change summary".

[Daniel Pitts]

I know this isn't strictly Java, but I'm using SVNKIT, which is Java

Our deployment process includes building a tag in SVN, which is "mostly"
the contents of an old tag, but with a couple of files copied from the
trunk instead.

I'm trying to build a tool which will do two things: One, it will list
the files that differ between trunk and the "source" tag. This is easy
with SVNKIT, just use the SVNDiffClient.doDiffStatus().

The second part seems to be more difficult. I want to produce a list of
commits that are different. Basically, I want to warn someone if are two
or more authors committed to the file that's being deployed, and also
give them a quick change-log.

I've written code that does this, which basically does a svn log of the
file both in the source tag and trunk, and then which trunk revisions
aren't already present in the tag. The problem is that this is a really
slow process, taking up to 30 seconds per file.

I'm using SVNKIT, I was using version 1.3.2, and recently upgraded to
1.7.4, which is somewhat faster, but still to slow.

Our current setup only allows http(s) connections to the repository (not
svn: or direct file access), so I'm not sure if that accounts for some
of the speed, but I doubt thats the entire problem. I don't have shell
access to the SVN server, so I can't really see whats going on there
without involving our admins.

The current revision number is r788228, so we have a lot of revisions.

Short of moving the revision history into my own DB (to cache the data),
is there any other approach you might consider taking to solve this
problem? Even questions/ideas I can take to our admins are fine, but
this is kind of a side-project for me, so I wouldn't expect a lot from them.

Thanks,
Daniel.

 

[Daniel Pitts]

I know this isn't strictly Java, but I'm using SVNKIT, which is Java

Our deployment process includes building a tag in SVN, which is "mostly"
the contents of an old tag, but with a couple of files copied from the
trunk instead.

I'm trying to build a tool which will do two things: One, it will list
the files that differ between trunk and the "source" tag. This is easy
with SVNKIT, just use the SVNDiffClient.doDiffStatus().

The second part seems to be more difficult. I want to produce a list of
commits that are different. Basically, I want to warn someone if are two
or more authors committed to the file that's being deployed, and also
give them a quick change-log.

I've written code that does this, which basically does a svn log of the
file both in the source tag and trunk, and then which trunk revisions
aren't already present in the tag. The problem is that this is a really
slow process, taking up to 30 seconds per file.

I'm using SVNKIT, I was using version 1.3.2, and recently upgraded to
1.7.4, which is somewhat faster, but still to slow.

Our current setup only allows http(s) connections to the repository (not
svn: or direct file access), so I'm not sure if that accounts for some
of the speed, but I doubt thats the entire problem. I don't have shell
access to the SVN server, so I can't really see whats going on there
without involving our admins.

The current revision number is r788228, so we have a lot of revisions.

Short of moving the revision history into my own DB (to cache the data),
is there any other approach you might consider taking to solve this
problem? Even questions/ideas I can take to our admins are fine, but
this is kind of a side-project for me, so I wouldn't expect a lot from
them.

Well, I did find one way to speed things up. An "info" request of the
file on the tag is relatively fast, and includes the "last change
revision" of that file. I can then do a log of that file on the trunk
(Which is faster by magnitudes), and anything after that revision can be
considered a change after that file was originally tagged.

Anyway, I'm still open to any other advice on the matter.

 

[John B. Matthews]

Well, I did find one way to speed things up. An "info" request of
the file on the tag is relatively fast, and includes the "last
change revision" of that file. I can then do a log of that file
on the trunk (Which is faster by magnitudes), and anything after
that revision can be considered a change after that file was
originally tagged.

Anyway, I'm still open to any other advice on the matter.

This reminds me of a project that had a particularly tangled
per-directory access control configuration. You might look at the
speed versus security tradeoff in "Disabling path-based checks."

 

[Steven Simpson]

Basically, I want to warn someone if are two or more authors committed
to the file that's being deployed,

I expect I haven't fully understood your requirements, but for that
specific one, could you use the equivalent of 'svn blame'?

 

[Daniel Pitts]

This reminds me of a project that had a particularly tangled
per-directory access control configuration. You might look at the
speed versus security tradeoff in "Disabling path-based checks."

I'm not sure I understand what you mean by that, but that does remind me
that our admins have prevented checkouts that don't have "/branches/*/",
"/tags/*/" or "/trunk/" in them. Not sure if that is contributing to the
problem or not.

 

[Daniel Pitts]

I expect I haven't fully understood your requirements, but for that
specific one, could you use the equivalent of 'svn blame'?

I thought about using that at first, it doesn't really help here. I have
two versions of the same file, and I need to know who's made the
difference. svn blame takes exactly one file.

In another post, I mentioned that svn info runs much faster for my
tagged file, and it returns basically the last revision that changed
that version of the file. I'm satisfied with this solution (unless I can
find "the perfect" solution). This is more of a "double check", so it
doesn't have to be perfect. The edge cases this misses are going to be
few and far between. It is already more information than people get
with our existing tool-set.

 

[John B. Matthews]

I'm not sure I understand what you mean by that, but that does
remind me that our admins have prevented checkouts that don't
have "/branches/*/", "/tags/*/" or "/trunk/" in them. Not sure if
that is contributing to the problem or not.

I'm not sure how they're enforcing it, but "Per-directory access
control" is one way, and "Disabling path-based checks" is one
alternative, both discussed here:

<http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.perdir>

A symptom is that the time required to obtain older `info`
increases (roughly) geometrically with age.

 

[Daniel Pitts]

I'm not sure how they're enforcing it, but "Per-directory access
control" is one way, and "Disabling path-based checks" is one
alternative, both discussed here:

<http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.perdir>

A symptom is that the time required to obtain older `info`
increases (roughly) geometrically with age.

That actually seems to be a likely cause. I'm going to ask our admins to
consider disabling path-based checks.

Thanks for the hint!