Hello Andrew,
Thanks for the reply. Comments below...
Rob.
> -----Original Message-----
> From: Reedick, Andrew [mailto:Andrew.Reedick@BellSouth.com]
> Sent: 06 October 2006 20:01
> To: Rob Hubbard; Subversion Mailing List (E-mail)
> Subject: RE: Feature Suggestions: Additional Revision Names
> UPDATED and
> COPIED
>
>
> > -----Original Message-----
> > From: Rob Hubbard [mailto:Rob.Hubbard@celoxica.com]
> > Sent: Friday, October 06, 2006 11:13 AM
> > To: Subversion Mailing List (E-mail)
> > Subject: Feature Suggestions: Additional Revision Names
> > UPDATED and COPIED
>
>
> > (1) UPDATED
> > =======
> >
> > It would be useful to be able to issue a command such as
> > svn log -rUPDATED
> > where "UPDATED" (or "LATEST" or something similar) is to
> > "HEAD" as "COMMITTED" is to "BASE".
> >
> > That is, "UPDATED" would refer to the most recently committed
> > revision of a given path, rather than globally in the
> > repository. It would be the same as "COMMITTED" in a WC that
> > is up to date.
> >
>
>
> Here's a workaround that makes UPDATED redundant for 'svn log':
> svn log --limit 1 URL
> svn log --limit 1 URL@150
> However, it would still be nice to have for 'svn info'.
>
>
> I have needed UPDATED type functionality before, but a keyword/alias
> seems awkward/inappropriate. Should it be more of a switch than a
> revision alias?
> svn log -r HEAD --find-last-changed URL
> svn info -r 150 --find-last-changed URL
Yes, that might be more flexible. The switch certainly has the advantage of being able to look backwards from any revision rather than just BASE.
Is there any reason why both shouldn't be provided (for symmetry with HEAD)?
So these would be the same:
svn log -r UPDATED URL
svn log -r BASE --find-last-changed URL
(svn log -r UPDATED --find-last-changed URL)
As would be these:
svn log -r COMMITTED URL
svn log -r HEAD --find-last-changed URL
(svn log -r COMMITTED --find-last-changed URL)
> What about the case where your revision is between two
> revisions? Ex:
> foo.java has two revisions, 100 and 200.
> You specify '-r 150'.
> You want log to report on r100 instead of the non-existent r150.
>
> Your way works if you specify a Peg Revision:
> svn log -r UPDATED URL@150
> or would a switch be cleaner?
> svn log -r 150 --find-last-changed URL
Good point; I hadn't got as far as considering pegging. Well, it could be that "file@REV" and "file -r REV" apply to different files.
Whatever method is settled on, if it is decided that this is worth implementing, should be sufficiently expressive to access the last changed predecessor of any point of any file "trail" in the repository.
I'm not too fussy whether it's a revision "alias", or an option.
> Instead of UPDATED, it might be better to match "svn info"'s "Last
> Changed Rev:" entry, say CHANGED, or LAST_CHANGED, or even
> LAST_CHANGED_REV to make it abundantly clear?
Yes, I agree. It should be consistent with any existing terminology.
Actually, UPDATED isn't such a good term as "updates" apply to WCs rather than repositories. So, yes, LAST_CHANGED, say, would be better in any case.
> >
> >
> > (2) COPIED
> > ======
> >
> > This name would also provide an alternative to --stop-on-copy.
> > svn log --stop-on-copy
> > would be the same as
> > svn log -rBASE:COPIED
> >
> > (I think having a name for the revision would be more useful
> > than an option such as "--just-at-copy".)
> >
> > In this case, I don't think a "CPREV" (meaning "COPIED-1")
> > would be useful.
> >
> >
> >
> >
>
> TAIL does sound better. I didn't see an enhancement request
> for TAIL in
> the issue tracker, though.
>
> A COPIED_PREV+1 (CPREV+1) could be useful for merge
> information. If you
> branched from trunk:100, then you need to merge from trunk:101 to
> trunk:HEAD. But anyone that lazy shouldn't be allowed to do merge
> tracking.
>
> CPREV/COPIED-1 isn't needed since the copy-from information is in the
> TAIL/COPIED revision.
>
>
> > I'm not sure what the behaviour of "COPIED" should be when
> > the path or URL was not copied. Perhaps "COPIED" should then be 0.
>
>
> COPIED is the TAIL of the branch, so this isn't a problem. Which is
> also why TAIL is a better name than COPIED.
>
>
> > (On the other hand a way of revealing the "copied-from"
> > information might be. In this case, there would need to be a
> > way to refer to the copied path as well as the copied
> > revision number, but I have not thought of a good way to
> > express that.)
>
> Your request to have the ability to specify certain fields (which I
> called a -fmt option ala ClearCase) would suffice. Ex:
> svn log -r TAIL -fmt "%Cn:%Cr\n" URL
> where '%Cn' is the copy-from name, and '%Cr' is the copy-from
> revision.
>
I am not familiar with SCMs having such a "format" option.
I think that that is an excellent suggestion.
_____________________________________________________________________
This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd.
This email and any files transmitted with it are confidential and
may be legally privileged. It is intended solely for the use of the
individual or entity to whom it is addressed. If you have received
this in error, please contact the sender and delete the material
immediately. Whilst this email has been swept for viruses, you
should carry out your own virus check before opening any
attachment. Celoxica Ltd accepts no liability for any loss or
damage which may be caused by software viruses or interception
or interruption of this email.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Oct 9 11:48:58 2006