John Rouillard wrote:
> On Thu, Mar 15, 2007 at 12:48:04PM -0600, Jeff Smith wrote:
>>>> Then why does cvs track them two different ways? Why to make it
>>>> more complicated, of course ;-)
>>> No, in cvs, a tag is just a label applied to a file/revision to
>>> make it easy to find a set with that label again and do group
>>> operations on them. Tags never divorce a file from its subsequent
>>> revisions as can happen in subversion.
>> Les, I think you misunderstood me. I agree with you, and what I said
>> *is* correct (except that I could not think of a good way to word
>> it). I atempted to describe the result of "what we do" with tags and
>> branches. You are thinking in terms of "why we do it" and cvs
>> internal workings, but I am saying to forget that for now. Anyway, in
>> that statement I was only explaining why `svn copy` is ideal for
>> tagging. When you say "No" as if I was wrong, either you
>> misunderstand or you are saying that Subversion has no 'tagging'
>> capability just because it only uses 'copy'.
My 'no' was about CVS tracking things in different ways. It only has
one way to track things and that is in the underlying rcs file that
contains everything for each versioned file. Everything related to the
file has to go there and you can't isolate any version in the repository
from its past and future revisions.
I think this covers most of the issue:
> The problem is that tags in subversion create a new namespace that
> ends the file time history at that point. E.G.
> new trunk/foo.c rev 1024
> new trunk/foo.c rev 1028
> tag trunk/tag1/foo.c -> tag/tag1/foo.c rev 1030
> new trunk/foo.c rev 1032
> you can look at the history for tag/tag1/foo.c and see that it came from
> trunk/foo.c at rev 1028, and IIRC you can see the change at 1024 and
> earlier. What you can't see is the new revision of trunk/foo.c at rev
> 1032 by looking at tag/tag1/foo.c.
> However what is tag/tag1/foo.c, it is just a particular stage of life
> of trunk/foo.c, but because of how SVN does tags, it isn't part of the
> timeline of trunk/foo.c at all. It is it's own seperate entity with
> it's own timeline.
Also in subversion, if you copy to a tag from your workspace (as you
must if you want your workspace mix of file revisions and others are
concurrently committing changes to the repository) you may also perhaps
accidentally include files that are not committed at all anywhere else.
In CVS the things that are tagged must be committed but you can tag at
the revision you have even if it isn't at the HEAD. You can access such
a file again by checking out the tag copy, but if you are expecting the
work to also appear ongoing in the trunk you won't know how to find it.
And one more thing: in CVS you can float tags from one place to another,
making it easy to do scripts that can build your RELEASE tag or perhaps
back up to a tag you left at the previous RELEASE location using known
names. You can sort-of emulate this in subversion by deleting a tag
(which will still exist in revision history) and creating a new one with
the same name but that feels conceptually different.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Mar 16 19:48:57 2007