Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #13563 > unrolled thread

Creating a subversion "tag change summary".

Back to article view | Back to comp.lang.java.programmer

Contents

  Creating a subversion "tag change summary". Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-04-15 14:44 -0700
    Re: Creating a subversion "tag change summary". Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-04-15 15:11 -0700
      Re: Creating a subversion "tag change summary". "John B. Matthews" <nospam@nospam.invalid> - 2012-04-16 01:51 -0400
        Re: Creating a subversion "tag change summary". Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-04-16 10:12 -0700
          Re: Creating a subversion "tag change summary". "John B. Matthews" <nospam@nospam.invalid> - 2012-04-16 20:54 -0400
            Re: Creating a subversion "tag change summary". Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-04-17 09:25 -0700
    Re: Creating a subversion "tag change summary". Steven Simpson <ss@domain.invalid> - 2012-04-16 08:10 +0100
      Re: Creating a subversion "tag change summary". Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-04-16 10:16 -0700

#13563 — 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.

[toc] | [next] | [standalone]

#13564

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.

[toc] | [prev] | [next] | [standalone]

#13573

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>

[toc] | [prev] | [next] | [standalone]

#13581

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.

[toc] | [prev] | [next] | [standalone]

#13601

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>

[toc] | [prev] | [next] | [standalone]

#13615

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!

[toc] | [prev] | [next] | [standalone]

#13574

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

[toc] | [prev] | [next] | [standalone]

#13582

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web