You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Peter Kahn <ci...@gmail.com> on 2007/03/02 15:04:11 UTC
CVS and SVN: Tags and Branches.. A question of strategies
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.
Our 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.
--
Peter Kahn
citizenkahn@gmail.com
citizenkahn@jabber80.com, pkahnpie1@AIM
http://kahnstipation.blogspot.com | http://analogoustendencies.blogspot.com/
Awareness - Intention - Action
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Les Mikesell <le...@gmail.com>.
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. On 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.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by James Tikalsky <TI...@michaels.com>.
________________________________
From: Peter Kahn [mailto:citizenkahn@gmail.com]
Sent: Monday, March 05, 2007 7:43 AM
To: info@soebes.de
Cc: users@subversion.tigris.org
Subject: Re: CVS and SVN: Tags and Branches.. A question of strategies
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.
________________________________
Forgive me if this is obvious, but I'm confused. You say that you copy
an existing tag and then update it with new versions of files from the
trunk/mainline? How then to you commit your revisions to the repository?
CVS tags are "sticky" (meaning that you can't change tagged files and
check in a revision) aren't they?
ASCII Art Diagram:
[Working Copy of Trunk] ------------|----------------------------->
[ongoing develoment]
Tag1 .
.
Copy of
Trunk Changes
After Tag1
.
.
[Working copy of Tag1] -------------| {Mix of Tag1 and trunk}
James Tikalsky
Fort Worth, TX
_____________________________________________________________________________
Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Peter Kahn <ci...@gmail.com>.
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.
On 3/3/07, Karl Heinz Marbaise < khmarbaise@gmx.de> wrote:
>
> 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.
> >
> > Our 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
> --
> SoftwareEntwicklung Beratung Schulung http://www.soebes.de
> Dipl.Ing.(FH) Karl Heinz Marbaise email: info@soebes.de
> Tel.: +49 (0) 2405 / 415 893 ICQ#: 135949029
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Peter Kahn
citizenkahn@gmail.com
citizenkahn@jabber80.com, pkahnpie1@AIM
http://kahnstipation.blogspot.com | http://analogoustendencies.blogspot.com/
Awareness - Intention - Action
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Kylo Ginsberg <ky...@gmail.com>.
On 3/28/07, Steve Bakke <st...@amd.com> wrote:
> > I just think subversion needs a more *convenient* way to cross-ref
> > from trunk to tags that branched from it. In the end, shoot, it
> > shouldn't bother me that all you can't do it. It doesn't stop me.
> >
>
> I totally agree. This was a strength of CVS tags that is seriously missing
> in subversion.
I totally agree also. We've just transitioned cvs->svn and a lot of
people are grousing about this lost functionality (sparse checkouts is
the other big loss).
I'm curious what other groups have done wrt this loss of
functionality. My ideas thus far are kludgy at best: e.g. define an
env variable with "branches of interest", and provide a script that
will provide a log aggregating history across the "branches of
interest". Ugh.
Other workarounds?
Thanks,
Kylo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Steve Bakke <st...@amd.com>.
On 3/28/07 1:32 PM, "Jeff Smith" <js...@robotronics.com> wrote:
>
> P.S. If you insist on looking up the file in trunk and seeing a "list"
> of tags, why not take the information and add a file property in
> trunk which lists these names matched with their revision? It can be
> automated.
Based upon answers to a prior question of mine, the only way you could do
this is to apply the properties to the files in trunk, commit that, and then
copy that revision to the tag.
>
> I just think subversion needs a more *convenient* way to cross-ref
> from trunk to tags that branched from it. In the end, shoot, it
> shouldn't bother me that all you can't do it. It doesn't stop me.
>
I totally agree. This was a strength of CVS tags that is seriously missing
in subversion.
> Also I'm wondering if the limitation is when you tag from a branch
> with mixed revisions. I'm not sure how that complicates my method.
> It's just that nobody is clarifying when I ask.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Jeff Smith <js...@robotronics.com>.
On Friday 23 March 2007 14:45, Les Mikesell wrote:
> 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.
Why is it that because I am not following what you say, it makes me
the one who is not lost??
Are you not seeing the same output I do when I look at the log of
"tag/tag1"?
"(from /trunk/foo.c:1028)"
It tells the file in the trunk that this tag was made from, as well as
precisely the revision number you are saying you cannot find. What
are you missing? Normally I would say "what am I missing" but it
seems I have all the information, but it's frustrating when there is
multiple people here talking about this being impossible, as if I am
invisible.
P.S. If you insist on looking up the file in trunk and seeing a "list"
of tags, why not take the information and add a file property in
trunk which lists these names matched with their revision? It can be
automated.
I just think subversion needs a more *convenient* way to cross-ref
from trunk to tags that branched from it. In the end, shoot, it
shouldn't bother me that all you can't do it. It doesn't stop me.
Also I'm wondering if the limitation is when you tag from a branch
with mixed revisions. I'm not sure how that complicates my method.
It's just that nobody is clarifying when I ask.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Les Mikesell <le...@gmail.com>.
Roy Franz wrote:
> On 3/23/07, Steve Bakke <st...@amd.com> wrote:
>> 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?
>>
>>
>> On 3/23/07 4:33 PM, "Les Mikesell" <le...@gmail.com> wrote:
>>
>> > Jeff Smith wrote:
>> >> On 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. Once 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.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Roy Franz <ro...@gmail.com>.
On 3/23/07, Steve Bakke <st...@amd.com> wrote:
> 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?
>
>
> On 3/23/07 4:33 PM, "Les Mikesell" <le...@gmail.com> wrote:
>
> > Jeff Smith wrote:
> >> On 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. Once 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.
Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Steve Bakke <st...@amd.com>.
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?
On 3/23/07 4:33 PM, "Les Mikesell" <le...@gmail.com> wrote:
> Jeff Smith wrote:
>> On 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Les Mikesell <le...@gmail.com>.
Jeff Smith wrote:
> On 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.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Jeff Smith <js...@robotronics.com>.
On 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Les Mikesell <le...@gmail.com>.
Jeff Smith wrote:
> On 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@1028. 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@1028.
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.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Jeff Smith <js...@robotronics.com>.
On 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
>
> 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.
Thanks John, I see. (And to Les, I had forgotten branches were just
tags marked as branches, so they are alike in cvs; we agree they
differ greatly from svn).
You are referring to the fact that because tag1 is a 'copy' of certain
rev of trunk, then trunk does not include tag1 as any part of it's
history. Frankly, given that svn only uses 'copy', I think it could
get overly complex if subversion tried to show "copied to..." in a
log entry, unless it was only done in a special case. After all, we
can make as many copies as we want, all in one node/revision of the
tree. I think it could get messy trying to show log of trunk if there
were 156 seperate copies steming from rev 1028. OTOH if you `svn log
-v tag/tag1/foo.c`, it's easy to display "(from /trunk/foo.c:1028)",
because there can only be one source.
> 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...
What is the "tag1" in svn? We see it's not just rev 12 of trunk, but
rather a 'copy' of trunk@1028. 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).
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@1028.
> 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.
Yeah, "has the file trunk/foo.c been updated since tag/tag1/foo.c". I
agree that we need something more to make the search fluent. I would
want a tool that does basically this, which I think would be cool
using svn libs rather than parsing commandline output:
> svn log tag/tag1 -v
------------------------------------------------------------------------
r1030 | (no author) | 2007-03-16 13:54:57 -0600 (Fri, 16 Mar 2007) | 1
line
Changed paths:
A /tag/tag1 (from /trunk:1028)
release tag1
------------------------------------------------------------------------
# from the log information above, derives "trunk@1028"
> svn log -r 1028:HEAD trunk@1028
------------------------------------------------------------------------
# No further changes are logged
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Roy Franz <ro...@gmail.com>.
On 3/16/07, John Rouillard <ro...@renesys.com> wrote:
> 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
I don't think that there is an easy answer to this question in subversion.
In CVS it was very easy to get a list of tags along with their
revision for a file, in SVN this is very difficult.
This is one of the bigger 'regressions' that we have come across in
our recent migration for CVS to subversion.
Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Les Mikesell <le...@gmail.com>.
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.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by John Rouillard <ro...@renesys.com>.
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
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Jeff Smith <js...@robotronics.com>.
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Les Mikesell <le...@gmail.com>.
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 svn://localhost/r/tags/build.2/sub
> 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?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Jeff Smith <js...@robotronics.com>.
On Monday 05 March 2007 10:17, Peter Kahn wrote:
> [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).
Peter,
It's possible that you are having a hard time leaving behind the
mind-boggling complexities of CVS. Subversion does same but simpler.
Maybe if you post an example as a sequence of one-liners (like I do
below) then one of us can help you work out the translation.
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 ;-)
I hope you will allow yourself to just forget how cvs works--wipe your
memory and start from a clean slate, just long enough to see the
_same_ procedures but from a subversion point of view. I am amazed
how easy it is to do the same thing using only 'copy'. BTW the reason
cvs does not use 'copy' instead of 'tag' is because it would have to
duplicate the entire contents of actual files in the repository, and
we don't want that kind of mass redundancy. That's why subversion
uses "cheap copies", i.e. new path only references the original.
How I do same stuff with Subversion:
(Note1 the paths are relative because I am in the root of my working
copy which contains trunk, tags, and branches. It could be done many
different ways for different benefits, so RTM)
(Note2 It is important to realize that sometimes `svn ci` and/or `svn
update` is needed even though I left it out)
1. Say I use /trunk/pname for our "mainline" development of the
"pname" project.
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 svn://localhost/r/tags/build.2/sub
branches/build.1-fix1/sub` :mixed revisions in this working copy
5. It builds and works, so I tag this as build.3
`svn cp branches/build.1-fix1 tags/build.3
I haven't tested these commands exactly, but I've used all of these
methods in the real world. Hope it helps clarify.
P.S. One difference from cvs to svn is which repository you commonly
use. Instead of setting env variable CVSROOT (because no equiv in
svn), I use this to shorten the commandline:
REP=svn://localhost/robo
cd branches/build.1-fix1/sub
svn switch $RROBO/tags/build.2/sub
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
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.
>
> Our 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
--
SoftwareEntwicklung Beratung Schulung http://www.soebes.de
Dipl.Ing.(FH) Karl Heinz Marbaise email: info@soebes.de
Tel.: +49 (0) 2405 / 415 893 ICQ#: 135949029
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: CVS and SVN: Tags and Branches.. A question of strategies
Posted by "L. Wayne Johnson" <wa...@zk.com>.
>>
>> > With CVS (in our shop) everyone works on mainline and we have tags for
>> > builds. If we have a new build that must have two bugs fix in it. We
>> > duplicate the last build tag and then update the copy to include the
>> files @
>> > the versions described in the bug. We then build from that tag.
>>
>> you can continue this practice; it's my understanding that this is
>> what was intended under SVN as well. it's just implemented in a
>> slightly different manner.
>>
This can be done in subversion by checking out the last tag, updating the
files included in the bug and then tagging your working copy (copy it to
tags.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: CVS and SVN: Tags and Branches.. A question of strategies
Posted by Andrew Close <ac...@gmail.com>.
Peter,
sorry i didn't respond earlier, i've been away from a computer...
i'm definitely not an SVN guru :) so i you may want to look elsewhere
for the answers to your questions.
> In CVS there are tags and branches. Branches are similar to SVN branches
> tags are something that doesn't really exist in SVN. Tags are similar to
> labels and are a group of files @ particular versions. The tag describes
> each file at a point in time (not necessarily the same point in time as the
> others). A tag can be altered to include newer or older versions of files.
in SVN tags and branches are really the same thing, cheap copies of
whatever you tagged/branched from. i believe tags just give you
another way to label a point in time. i use tags for snapshots that
aren't supposed to be changed, but we're not enforcing that at the
moment. i believe anyone could go in and modify tagged code...
branches are working copies that we don't want integrated into the
mainline until they are stable. we do continue to make changes on
them until they are folded back into the trunk, at which point they'll
sit around for some period of time for historical reasons and then
we'll eventually purge them.
> With CVS (in our shop) everyone works on mainline and we have tags for
> builds. If we have a new build that must have two bugs fix in it. We
> duplicate the last build tag and then update the copy to include the files @
> the versions described in the bug. We then build from that tag.
you can continue this practice; it's my understanding that this is
what was intended under SVN as well. it's just implemented in a
slightly different manner.
> ****
> My question is what's the right way to do that in SVN since a flexible
> device that allows for the setting of individual versions of file doesn't
> realy exist (except to branch and merge).
>
> ****
as mentioned above, i believe you can continue on with your current
practice using tags as snapshots for releases. you just set procedure
to dictate that tags are not supposed to be touched once they're
created. all 'work' should be done on either the trunk or a branch.
i'm not sure i completely answered your question. hopefully that
helps though, or someone else is able to provide a more clear answer.
:)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org