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

Re: Re: CVS/SVN comparison

From: Raye Raskin <rayer_at_pobox.com>
Date: 2004-10-25 06:25:49 CEST

> From: "HAND,Nathan" <Nathan.HAND@dewr.gov.au>
> To: "Scott Palmer" <scott.palmer@2connected.org>
> Cc: <users@subversion.tigris.org>
> Sent: Sunday, October 24, 2004 6:34 PM
> Subject: RE: Re: CVS/SVN comparison
>

> Ok, I think I see your point. You're saying http://.../tags/1.0 isn't a
> tag because somebody can commit a change to that URL. That makes sense.
>
> Would it be sufficient to specify a tag as both a revision and a URL?
> That tag is immutable because every subsequent change results in a new
> revision. So...
>
> svn -r 12345 checkout http://.../tags/my-tag
>
> The tuple (12345,http://.../tags/my-tag) should be immutable. Or have I
> misunderstood the problem?

That would work. But the revision number (12345) is not typically
going to be in your hip pocket every time you need it.

One way to get it would be:

  svn log http://.../tags/my-tag

...the output of which will be all commits to that tag (if any)
and the historical parent hierarchy, in reverse chronological
order. If there haven't been any commits to my-tag, then the
very first log entry will be the tag-point revision, e.g.:

------------------------------------------------------------------------
r2 | rayer | 2004-09-29 16:51:58 -0700 (Wed, 29 Sep 2004) | 2 lines

This is the initial my-tag branch point.
------------------------------------------------------------------------

If there HAVE been any commits to this tag, they would show up
before the r2 log entry, and this would of course make it a
little tricky to handle in a script.

But just like the -F argument to "cvs tag" there might be times
when you actually WANT to alter a tag a little...

The more I think about this issue, and read threads about it,
the more I'm thinking the current implemented method(s) are
the right ones, wherein the SVN administrator must "open up"
a directory under ./tags to be something other than read-only.
That way, the HEAD revision is always the "correct" version
of the given, er, tag. This accomplishes two things. First,
not everybody has the knowledge/passwords to actually do it,
thus it's "safer" than "cvs -F tag". Second, a real conscious
decision has to be made to actually get it done, again making
it safer than just adding a new command line argument to svn.

Raye <-- Now I go back to lurking...

> > -----Original Message-----
> > From: Scott Palmer [mailto:scott.palmer@2connected.org]
> > Sent: Saturday, October 23, 2004 5:19 AM
> > To: John Szakmeister
> > Cc: users@subversion.tigris.org
> > Subject: Re: CVS/SVN comparison
> >
> >
> >
> > On Oct 22, 2004, at 2:31 PM, John Szakmeister wrote:
> >
> > > On Friday 22 October 2004 13:57, Scott Palmer wrote:
> > >
> > >> For ease of use the svn copy command could have a flag to say I'm
> > >> making a "tag" copy, and the "tag" property would automatically be
> > >> set on the copy.
> > >
> > > What's so hard about svn cp http://.../trunk http://.../tags/1.0?
> >
> > I'm not suggesting anything is hard about it. I'm simply saying that
> > it does not result in a (reasonably) immutable copy.. which is *my*
> > definition of a tag, and there are obviously many others that have an
> > equivalent definition of what a tag should be.
> >
> > Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Oct 25 06:26:33 2004

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.