----- Original Message -----
From: "Raye Raskin" <rayer@pobox.com>
To: <users@subversion.tigris.org>
Sent: Sunday, October 24, 2004 9:25 PM
Subject: Re: Re: CVS/SVN comparison
>> 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.
> ------------------------------------------------------------------------
Sorry for the bogus log message above. I took it from a branch
I created. I should not have used the word "branch"! :-(
> 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 09:40:55 2004