On Thu, Mar 15, 2007 at 12:48:04PM -0600, Jeff Smith wrote:
> On Thursday 08 March 2007 10:45, Les Mikesell wrote:
> > > I can tell that deep down you know the two are much the same:
> > > * A [tag] is a tree of files given a name, and selected from
> > > certain revisions of certain files.
> > > * A [branch] is a tree of files given a name, and selected from
> > > certain revisions of certain files.
> > >
> > > 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'.
>
> I do hope you could clarify what you mean though, that subversion
> could "divorce a file from it's subsequent revisions". Did you mean
> somehow it could lose the history, in what situation?
>
> I realize it's probably not the question of this thread. I've learned
> I just can't understand anything without making sure I understand
> it's precepts.
>
> > I think the unanswered question is, starting from a subversion tag
> > copy, where subsequent work has been done on the corresponding files
> > in branch/trunk copies, how do you take only the tagged files, but
> > advance them to HEAD (or some arbitrary rev number)? In cvs, since
> > all revisions exist in a single versioned file, you can look
> > 'forward' past the tag. What is the equivalent subversion
> > operation, especially for tags copied from a working copy where the
> > tagged revision may not match anything else in the repository?
>
> Although I still don't see any problem with doing all this in
> subversion, I just don't see any example to use. Could someone spell
> out the problem in steps, and maybe how it is done in cvs?
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.
Looking at the history of trunk/foo.c doesn't give any indication
where tag/tag1/foo.c was created. The only way you can tell that there
was a tag there is to look at the log messages which is error prone to
say the least and doesn't lend itself well to automation (e.g. drawing
a tag/branch graph).
So if my question is "has the file tag/tag1/foo.c" changed/been
updated, then answer is no always. But what I really mean is: has the
file that tag/tag1/foo.c was the tag of been updated? I have no way to
tell from looking at tag/tag1/foo.c. I must go back to the base file
and pick up it's time history. In cvs, tags don't create a seperate
timeline. They mark a point in the timeline of the original file.
So my question becomes is there a revision of trunk/foo.c that is
newer than the tag tag1 of that 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 Fri Mar 16 14:30:04 2007