Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   Creating a subversion "tag change summary". (http://www.velocityreviews.com/forums/t945417-creating-a-subversion-tag-change-summary.html)

Daniel Pitts 04-15-2012 09:44 PM

Creating a subversion "tag change summary".
 
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 04-15-2012 10:11 PM

Re: Creating a subversion "tag change summary".
 
On 4/15/12 2:44 PM, Daniel Pitts wrote:
> 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 04-16-2012 05:51 AM

Re: Creating a subversion "tag change summary".
 
In article <HIHir.9015$YM2.6283@newsfe05.iad>,
Daniel Pitts <newsgroup.nospam@virtualinfinity.net> wrote:

> 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."

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Steven Simpson 04-16-2012 07:10 AM

Re: Creating a subversion "tag change summary".
 
On 15/04/12 22:44, Daniel Pitts wrote:
> 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'?

--
ss at comp dot lancs dot ac dot uk


Daniel Pitts 04-16-2012 05:12 PM

Re: Creating a subversion "tag change summary".
 
On 4/15/12 10:51 PM, John B. Matthews wrote:
> In article<HIHir.9015$YM2.6283@newsfe05.iad>,
> Daniel Pitts<newsgroup.nospam@virtualinfinity.net> wrote:
>
>> 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."
>

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 04-16-2012 05:16 PM

Re: Creating a subversion "tag change summary".
 
On 4/16/12 12:10 AM, Steven Simpson wrote:
> On 15/04/12 22:44, Daniel Pitts wrote:
>> 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'?
>


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 04-17-2012 12:54 AM

Re: Creating a subversion "tag change summary".
 
In article <LpYir.88442$s82.47213@newsfe10.iad>,
Daniel Pitts <newsgroup.nospam@virtualinfinity.net> wrote:

> On 4/15/12 10:51 PM, John B. Matthews wrote:
> > In article<HIHir.9015$YM2.6283@newsfe05.iad>,
> > Daniel Pitts<newsgroup.nospam@virtualinfinity.net> wrote:
> >
> >> 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."
> >

> 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.

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Daniel Pitts 04-17-2012 04:25 PM

Re: Creating a subversion "tag change summary".
 
On 4/16/12 5:54 PM, John B. Matthews wrote:
> In article<LpYir.88442$s82.47213@newsfe10.iad>,
> Daniel Pitts<newsgroup.nospam@virtualinfinity.net> wrote:
>
>> On 4/15/12 10:51 PM, John B. Matthews wrote:
>>> In article<HIHir.9015$YM2.6283@newsfe05.iad>,
>>> Daniel Pitts<newsgroup.nospam@virtualinfinity.net> wrote:
>>>
>>>> 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."
>>>

>> 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.

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!


All times are GMT. The time now is 12:06 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.