Daniel
Thank you for your quick reply. The changed option does indeed give the
correct content; however, it has the 'U" in the front of the line and the
svnlog.pl that I have created returns the full URL to the user with the http
prepended in the front of the line. Thus, the 'tree' option with the
"--full-paths" option is preferred.
I have a modified version of the original code I sent out that checks to see
if the user requested both the 'tree' and the '-r' option. This could be
submitted as a "PATCH" item.
We can close this email thread since it appears that my request is an
enhancement and not a bug fix.
John Huddleston
-----Original Message-----
From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.co.il]
Sent: Sunday, June 08, 2008 7:23 AM
To: John Huddleston
Cc: dev_at_subversion.tigris.org; users_at_subversion.tigris.org
Subject: RE: SVNLOOK tree strictly obeying the version
[ CCing users@ list, since it's no longer about a patch ]
John Huddleston wrote on Sun, 8 Jun 2008 at 06:46 -0600:
> Daniel,
>
> I'm sorry if my original email to this group was terse.
>
(I was going to say the same about my last email.)
> If you elect to use the "-r" option of the svnlook command, one would hope
> that you would only get records that that been touched (like an existing
> directory), added, modified, or even deleted.
>
Please try 'svnlook changed -r'.
> The behavior is that there are revisions being displayed that are not the
> ones the user requested. This is the spurious data.
>
> You said "It's a few megabytes of output, what's wrong with it?"
>
> If you do not see a problem in getting information that does not conform
to
> the user's request, then that must have been the original design of the
> program.
>
Yes.
'svnlook changed -r' prints the paths that were modified in a given
revision.
'svnlook tree -r' prints the entire versioned filesystem tree (like 'svn
ls -R -r') as it existed in a given revision.
Daniel
> John Huddleston
>
>
>
> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.co.il]
> Sent: Saturday, June 07, 2008 9:32 AM
> To: John Huddleston
> Cc: dev_at_subversion.tigris.org
> Subject: RE: SVNLOOK tree strictly obeying the version
>
> John Huddleston wrote on Sat, 7 Jun 2008 at 09:10 -0600:
> > Daniel
> >
> > I have five or sixe different subversion repositories that manifest this
> > behavior.
> >
>
> *Which* behaviour? You still have not explained why you think the
> output is wrong, which was my original question.
>
> > svnlook tree --show-ids --full-paths /my/repos/path
> >
> > Some were created with the 1.4.5 version and some older one were created
> > with 1.4.3
> >
> > Try it for your self on the subversion repository.
> >
> > svnlook tree --show-ids --full-paths /your/path/to/collabnet/subversion
|
> > grep -v r31623
> >
>
> It's a few megabytes of output, what's wrong with it?
>
> % svnlook help tree
> tree: usage: svnlook tree REPOS_PATH [PATH_IN_REPOS]
>
> Print the tree, starting at PATH_IN_REPOS (if supplied, at the root
> of the tree otherwise), optionally showing node revision ids.
>
> Originally you said that that the "spurious data" was output when you
> passed 'the "-r" option to the "svnlook tree" command'. The above
> command does use that option, and does cannot logically trigger the bug
> you originally reported (and tried to fix).
>
> (see below for more...)
>
> > John Huddleston
> >
> > -----Original Message-----
> > From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.co.il]
> > Sent: Sunday, June 01, 2008 10:41 AM
> > To: John Huddleston
> > Cc: dev_at_subversion.tigris.org
> > Subject: Re: SVNLOOK tree strictly obeying the version
> >
> > John Huddleston wrote on Sat, 31 May 2008 at 06:59 -0600:
> > > Hi,
> > >
> > >
> > > I was setting up a post-commit svnlog.pl perl script for a customer
and
> > they
> > > wanted the viewvc URL of the changed files sent to them via email.
>
> % svnlook help changed
> changed: usage: svnlook changed REPOS_PATH
>
> Print the paths that were changed.
>
> Daniel
>
> > > During
> > > the process of programming I noticed that the "-r" option to the
> "svnlook
> > > tree" command returned some spurious data.
> > >
> >
> > Can you provide a recipe (starting with an empty repository) that causes
> > svnlook to produce spurious data? Or at least, explain to us what the
bug
>
> > is, before you start fixing it :)
> >
> > By "recipe", I mean a script of the form:
> >
> > svnadmin create repos
> > svn co `pwd`/repos wc
> > cd wc
> > ### make some commits
> > svnlook tree ../repos -r REV
> >
> > Thanks,
> >
> > Daniel
> >
> > P.S. For reference, please read
> > http://subversion.tigris.org/hacking.html#patches. Following the
> > guidelines there makes it easier for us to process your patch, which
makes
>
> > it more likely that it will be applied.
> >
> > >
> > >
> > > I checked out the most recent code from your subversion server and
> edited
> > > the main.c under
> http://svn.collab.net/repos/svn/trunk/subversion/svnlook
> > to
> > > print the requested revisions.
> > >
> > >
> > >
> > > I apologize if it is not elegant but this was my first foray into
> > modifying
> > > any of this code. In short, I needed to pass the revision from the
> > > svnlook_ctxt_t and then compare it to the revision in the database.
> > >
> > >
> > >
> > > I've attached an svn diff file with the changes. The work was done on
> > > Windows working under Cygwin.
> > >
> > >
> > >
> > > John Huddleston
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> > For additional commands, e-mail: dev-help_at_subversion.tigris.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-08 17:29:39 CEST