Can someone let me know what is a good way to approximate cvs tagging in svn
or
if asking such a question means I'm trapped in a cvs mindset?
I'm trying to figure out how my team's processes will change as we move from
cvs to svn. I'm a long time svn administrator and long to move from cvs
back to a more modern SCM.
My requirement is to be able to build a copy of the last build + specific
changes only.
example:
I'm building build.2 and it has 3 fixed bugs with associated revisions.
I need build.1 + those changes with no others included.
cvs process is:
- take the build_1 tag and clone it as build_2
- update the build_2 tag to include the bug fixed files at the right
versions
- build from the build_2 tag
In svn, there are no tags only branches and revisions. So, it looks like
I'd need to:
- branch build_2 from the build_1 branch
- merge over the changes from a mainline to branch_2 (hoping that there will
be no conflicts.
- build from the build_2 branch
This seems complex to me. It feels like I'm bending subversion to
accommodate a practice that may have been valid for CVS, but makes no sense
in a SVN environment. does it seem like i'm trapped in a CVS mindset?
Well, I'd appreciate any feed back on this, because I'd really like to get
this right Thanks.

Hi Peter,

My requirement is to be able to build a copy of the last build +
specific changes only.
example:
I'm building build.2 and it has 3 fixed bugs with associated revisions.
I need build.1 + those changes with no others included.

cvs process is:
- take the build_1 tag and clone it as build_2
- update the build_2 tag to include the bug fixed files at the right
versions
- build from the build_2 tag
If i understand this process well it seemed to me that you've used
branches instead of tags, may be you can give a little more details
e.g. how you did this in CVS (i appreciate to learn things)

In svn, there are no tags only branches and revisions.
This statement is from the technical point of view correct, but if you
take the view that you define a tag as an read-only area then you are at
the point of CVS, cause in CVS you have to make a decision between tag
(cvs tag) and branching (cvs tag -b).

The way you decide between tags and branches in SVN is currently only an
agreement, which means you put a tag into the "project/tags" directory
and a branch into the "project/branches" directory.

Kind regards
Karl Heinz Marbaise

Thanks for the info. My basic question is
"what's the best way to replicate the following CVS promotion based
development pattern in SVN":
- all developers work on mainline
- when we have a new build, we duplicate an existing tag and
update it with new versions of files on the mainline.
- the new tag contains some, but not all updates since the last
build.

[for those unfamiliar with cvs, a tag can be viewed as a group of files
each at a specific version]

So, I'd like to have a flexible structure that allows me to group a variety
of different versions of files together and call them a build. In CVS, I
can use a tag (or a branch as well) for this. In SVN, I believe that my
only option is to branch & merge (agreed, with the tags branches being read
only after creation).

Finally, its possible that SVN isn't an option for us because the benefit of
tags is so great that another SCM (like p4 perhaps) is a better fit for our
environment. If that is the case, then we'll look elsewhere, I just want
to make sure that I'm not missing something here

{it is also possible that our current promotion model isn't ideal either and
was developed only because of how CVS handles branching}

Thanks again.

3/3/07, Karl Heinz Marbaise < khmarbaise (AT) gmx (DOT) dewrote:

Hi Peter,

My requirement is to be able to build a copy of the last build +
specific changes only.
example:
I'm building build.2 and it has 3 fixed bugs with associated revisions.
I need build.1 + those changes with no others included.

cvs process is:
- take the build_1 tag and clone it as build_2
- update the build_2 tag to include the bug fixed files at the right
versions
- build from the build_2 tag
If i understand this process well it seemed to me that you've used
branches instead of tags, may be you can give a little more details
e.g. how you did this in CVS (i appreciate to learn things)
--
In svn, there are no tags only branches and revisions.
This statement is from the technical point of view correct, but if you
take the view that you define a tag as an read-only area then you are at
the point of CVS, cause in CVS you have to make a decision between tag
(cvs tag) and branching (cvs tag -b).

The way you decide between tags and branches in SVN is currently only an
agreement, which means you put a tag into the "project/tags" directory
and a branch into the "project/branches" directory.
--
Kind regards
Karl Heinz Marbaise

Peter Kahn wrote:
Thanks for the info. My basic question is
"what's the best way to replicate the following CVS promotion based
development pattern in SVN":
- all developers work on mainline
- when we have a new build, we duplicate an existing tag and
update it with new versions of files on the mainline.
- the new tag contains some, but not all updates since the
last build.

[for those unfamiliar with cvs, a tag can be viewed as a group of
files each at a specific version]

So, I'd like to have a flexible structure that allows me to group a
variety of different versions of files together and call them a build.
In CVS, I can use a tag (or a branch as well) for this. In SVN, I
believe that my only option is to branch & merge (agreed, with the tags
branches being read only after creation).

Not necessarily. In svn you can create a workspace containing whatever
you want and copy it directly to a tag that you use for the build or
whatever future use of that snapshot you might have.

Finally, its possible that SVN isn't an option for us because the
benefit of tags is so great that another SCM (like p4 perhaps) is a
better fit for our environment.

Since you are using tags for ongoing changes, a branch might be a better
fit in svn. However the only reason you really need branches is if you
need to isolate concurrent development versions from each other. Your
workflow description makes it sound like you always want to group a set
of files that have been tagged and update only those files for the next
release even though other updated files exist in the trunk. That
doesn't sound sustainable over long periods. I'd expect most projects
to eventually have more arbitrary changes where old functionality is
refactored into different files unless you are limiting your development
style to fit your workflow. In any case, a branch is a good fit for
continued support of old versions (using tags as snapshot points) while
the trunk diverges and merging the changes you want probably won't be
any harder than collecting the updates you want in cvs is now. the
other hand if you mostly just follow the trunk for continuous updates
you can gather what you want in a workspace, be sure any modifications
you make there are committed, and copy from there to a tag.

Jeff Smith wrote:
I perceive that you have trouble because you are keeping in your mind
the two different ways that cvs tracks tags and branches internally.
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.

2. Soon I have some releases which I have tagged:
`svn copy trunk/pname tags/build.1` :tag current dir as "build.1"
`svn copy trunk/pname tags/build.2` :tag current dir as "build.2"

3. I want to work off of build.1 now for small bugfix.
`svn copy tags/build.1 branches/build.1-fix1` :branch from "build.1"
[fix bug in branches/build.1-fix1]
>
4. I realize I need "sub" folder to be at build.2
`svn switch
branches/build.1-fix1/sub` :mixed revisions in this working copy

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?

Thu, Mar 15, 2007 at 12:48:04PM -0600, Jeff Smith wrote:
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.

3/16/07, John Rouillard <rouilj (AT) renesys (DOT) comwrote:
Thu, Mar 15, 2007 at 12:48:04PM -0600, Jeff Smith wrote:
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.

John Rouillard wrote:
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.

Jeff Smith wrote:
Friday 16 March 2007 08:30, John Rouillard wrote:
>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
>>

>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.

So this is where use of cvs and svn are designed to differ, and I
guess if you relied on the internal cvs specifics then some
reconsideration is in order

I don't think they are designed to differ so much as it happens as an
effect of the mechanism.

What is the "tag1" in svn? We see it's not just rev 12 of trunk, but
rather a 'copy' of trunk (AT) 1028 (DOT) I think the begining of your solution
is knowing that the 'tag' by name (i.e. tag/tag1), tells you which
revision it is tagging (trunk@1028).

In cvs, it might not be, since your work flow might involve floating a
known tag name to where you want it for the next operation. In either,
you may have tagged a mixed revision of files if other people were
committing while you were evaluating your workspace before tagging - or
for other reasons.

I guess what I'm still missing is the real-world example of your cvs
project; why the hints that you don't know the name of the tags, but
you only know the origin "trunk/foo.c"? Instead, I thought it would
just be a matter of looking at the tag1 log to see what rev it was
coppied from. Then you know you're working from trunk (AT) 1028 (DOT)

The point is more that you can't look backwards from the trunk copy (or
maybe some branch) and see at what point the tag was applied. In the
case of tagging from the workspace there may be no exactly matching rev
anywhere else. And you can't look forward from the tag copy because the
history ends there. The example this thread started from was someone
wanting to check out a tag, then update only that set of files to the
matching trunk/HEAD versions without picking up additional files that
weren't included in the tag.

Jeff Smith wrote:
Friday 16 March 2007 16:45, Les Mikesell wrote:
>The point is more that you can't look backwards from the trunk copy
>(or maybe some branch) and see at what point the tag was applied.

In either VCS, don't you have to know the name of the tag before you
can look for it? My point is if you know the tag is named "tag/tag1",
you don't have to look in "trunk" for that tag. The name already
tells where it is. Then you have only to look there to see where it
came from. I don't see any ability that is lost.

There is no problem getting an exact copy of the tagged version back and
from the tagged version you can see it's history. The problem is
knowing how a file in that version relates to anything else. Looking at
a file of the same name in the trunk/HEAD you can't tell at what point
the tag was applied or even if the file had been deleted and recreated
since then and no longer shares any history. Likewise from the tag, you
can't follow the 'future' revisions that may or may not exist in the
trunk or other branches.

Roy Franz wrote:
3/23/07, Steve Bakke <steven.bakke (AT) amd (DOT) comwrote:
>Would it be possible to set a property on the specific revision of a file
>which would indicate which tag the revision is included in?
>>
>>
>3/23/07 4:33 PM, "Les Mikesell" <lesmikesell (AT) gmail (DOT) comwrote:
>>
>Jeff Smith wrote:
>>Friday 16 March 2007 16:45, Les Mikesell wrote:
>The point is more that you can't look backwards from the trunk copy
>(or maybe some branch) and see at what point the tag was applied.
>>>
>>In either VCS, don't you have to know the name of the tag before you
>>can look for it? My point is if you know the tag is named "tag/tag1",
>>you don't have to look in "trunk" for that tag. The name already
>>tells where it is. Then you have only to look there to see where it
>>came from. I don't see any ability that is lost.
>>
>There is no problem getting an exact copy of the tagged version back
>and
>from the tagged version you can see it's history. The problem is
>knowing how a file in that version relates to anything else.
>Looking at
>a file of the same name in the trunk/HEAD you can't tell at what point
>the tag was applied or even if the file had been deleted and recreated
>since then and no longer shares any history. Likewise from the tag,
>you
>can't follow the 'future' revisions that may or may not exist in the
>trunk or other branches.
>>

Not really, as creating (or updating) that property creates a new
revision of the file in question. a revision is created, it
cannot be changed, so you can't go back after the fact an update
properties. (revision properties, or rev-props are different, but
they are per-revision, not per file.)

Getting the branch/tag 'meta-data' about a file is much harder in
subversion than CVS, and I don't see any easy way to 'fix' it. I have
not seen any tools that really help here, I think that most people
have just learned to not try to get that information from subversion.

I've always considered the cvsweb/viewvc views of a cvs item to be
extremely handy, since you can see what revisions have which tags and
what branches are related.