[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Feature Suggestions: Additional Revision Names UPDATED and COPIED

From: Reedick, Andrew <Andrew.Reedick_at_BellSouth.com>
Date: 2006-10-06 21:00:30 CEST

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

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

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

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?

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

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.


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 6 21:01:29 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.