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

Re: Is label support in future release?

From: John Rouillard <rouilj_at_renesys.com>
Date: 2006-11-21 17:22:16 CET

On Tue, Nov 21, 2006 at 01:29:53AM -0600, Ryan Schmidt wrote:
> On Nov 20, 2006, at 19:28, John Rouillard wrote:
> [Hypothetical syntax for creating a label:]
> >With labels I:
> >
> > svn label -r 195 PRODUCTION http://repo/config/trunk/ldap/
> >ldap.conf.solaris
> > svn label -r 196 PRODUCTION http://repo/config/trunk/ldap/
> >ldap.conf.linux
> > svn label -r 199 PRODUCTION http://repo/config/trunk/ldap/
> >ldap.conf.aix
> >
> >(note no working copy needed). Or maybe:
> >
> > svn label PRODUCTION http://repo/config/trunk/ldap/
> >ldap.conf.solaris@195 \
> > http://repo/config/trunk/ldap/ldap.conf.linux@196 \
> > http://repo/config/trunk/ldap/ldap.conf.aix@199
> If I understand your example, and you are suggesting potential
> syntaxes for creating a label, and you are intending these to be
> equivalent, then I must recommend the former, not the latter, because
> the latter is not what the peg revision syntax "URL@PEGREV" currently
> means. "URL@PEGREV" currently means "Find the object URL in
> repository revision PEGREV and get its HEAD revision" which I don't
> think is what you intended.

I think they are equivalent aren't they? Well assuming:

  that the URL exists in all revisions between HEAD and PEG.

which should be made explicit I guess.

If I last changed URL in revision 195 then don't

  -r 195 URL


mean the same thing? As revision 195 will be the HEAD revision of that
URL when the repository is at version 195 (it was just checked in to
create revision 195 in fact). The only time they might not be is if
the URL had been removed at some point by a move or rename operation
IIRC. But even in that case as long as I specify the revision that
file actually changed in it should be equivalent.

If I am wrong can you describe the scenario where this doesn't work as I
am not seeing it from the pegrevs doc.

Also the second way should be atomic where the first isn't.
> The operative revision syntax "-r OPREV URL", on the other hand,
> which I believe is what you do want, means "Find the object URL in
> the repository's HEAD revision, and get its revision OPREV."
> More generally, combining the two, there is "-r OPREV URL@PEGREV"
> which means "Find the object URL in repository revision PEGREV and
> get its revision OPREV." Omitting either of these revisions defaults
> it to HEAD.

Isn't this just going around the block clockwise and counter clockwise
in the case where the revision lineage of the URL is unbroken? You end
up at the same place.

   start at HEAD on URL and backtrack to OPREV down an unbroken prior
       revision line.

   start at version PEG and well go to HEAD (which is that same

as long as PEG and OPREV are the same number is should be the same right?
> FYI, peg revision documentation:
> http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html

Yup. Sadly read it often (and just reread) and showed it to people
trying to find an earlier version of a removed file.

				-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 21 17:27:08 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.