You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Weintraub <qa...@gmail.com> on 2011/04/01 02:13:47 UTC
Re: Using tags with SVN
On Thu, Mar 31, 2011 at 12:31 PM, Stirnweiss, Siegmund SZ/HZA-ZIT3
<st...@schaeffler.com> wrote:
> Hello,
>
> I’m currently thinking about migrating from CVS to SVN, since SVN is said to
> be the successor of CVS.
>
> When analyzing the differences between CVS and SVN I found tags are treated
> in a different way in SVN, than they were treated in CVS, because the tag
> concept in SVN is: A tag is just a “snapshot” of a project in time.
Tags are suppose to be "snapshots" of a particular version of the
application. Sometimes you can adjust a tag if you've tagged the wrong
file, but that should be fairly rare. In Subversion, tags take less
than a second to do while in CVS, you have to tag each and every file.
Long files have to be rewritten after every tag. That, to me is a
great advantage in Subversion.
> We use tags in CVS to identify the files which have passed module tests and
> should make it into our integration test environment. When they have passed
> the integration tests we use a different tag to identify the files, which
> make up the software in/for our production environment. In addition to that
> our development model is not release driven. As a result we do not tag the
> HEAD of our complete source tree at a particular point in time.
Whoa! That's dangerous. When you pick and choose tags, you may end up
tagging the wrong file. Then, this is a CM error and not a developer
error. That means the Finger o' Blame points to you and not to the
developer who gave you the wrong file or forgot a file. You want that
Finger o' Blame pointing not at you.
I just came to my current position a couple of months ago, and that's
exactly what we were doing. Tagging particular files, and then
attempting to build from that tag. I put an immediate stop to that. We
build on the head of the branches now. That has eliminated about half
of our build errors and deployments go much smoother.
Now, there's nothing in Subversion preventing you from attaching a tag
to a particular version of a file. You simply copy files to the tag
directory one at a time. When a file gets approved, you "tag" it. It's
not the standard way to do it, but I've seen shops that do.
Even better, Subversion tracks when things were tagged and branched.
In CVS, you have no idea when a tag or a branch was created and
applied.
--
David Weintraub
qazwart@gmail.com
Re: Using tags with SVN
Posted by Les Mikesell <le...@gmail.com>.
On 4/1/2011 7:52 AM, Stirnweiss, Siegmund SZ/HZA-ZIT3 wrote:
>
>> Sometimes you can adjust a tag if you've tagged the wrong
>> file, but that should be fairly rare. In Subversion, tags take less
>> than a second to do while in CVS, you have to tag each and every file.
>> Long files have to be rewritten after every tag. That, to me is a
>> great advantage in Subversion.
>
> Having to tag each and every file in cvs for us is a feature. It helps
> us achieving our goal in a very convenient way.
In cvs, you _have_ to tag files to get any sort of grouping. It is the
only way to tie a set of files at specific revisions together. Svn
works naturally with directories, so normally you want to replace the
concept of using tags on files to hold a group together with organizing
the layout under directories (which probably already exist...) and using
the repository global revision number for a particular state.
>>> We use tags in CVS to identify the files which have passed module
> tests and
>>> should make it into our integration test environment. When they have
> passed
>>> the integration tests we use a different tag to identify the files,
> which
>>> make up the software in/for our production environment. In addition
> to that
>>> our development model is not release driven. As a result we do not
> tag the
>>> HEAD of our complete source tree at a particular point in time.
>
>> Whoa! That's dangerous. When you pick and choose tags, you may end up
>> tagging the wrong file. Then, this is a CM error and not a developer
>> error. That means the Finger o' Blame points to you and not to the
>> developer who gave you the wrong file or forgot a file. You want that
>> Finger o' Blame pointing not at you.
>
> That's not the problem here. The developers themselves tag files and we
> have not yet had a problem with this approach.
In svn, you might want to use a more directory-oriented approach. It
would be more typical to copy the top level project to a QA/release
branch and keep making changes there until all the files pass QA,
perhaps making tag copies as you go, but you could copy file-by-file
into the branch if you don't want them to appear all at once.
>> Now, there's nothing in Subversion preventing you from attaching a tag
>> to a particular version of a file. You simply copy files to the tag
>> directory one at a time. When a file gets approved, you "tag" it. It's
>> not the standard way to do it, but I've seen shops that do.
>
> What exactly do you mean with copy? Do you mean a "svn copy"? Or do you
> mean a file system copy?
Always "svn copy" - but it can be in some developer's working copy that
is subsequently committed or a url->url repository operation.
--
Les Mikesell
lesmikesell@gmail.com
Re: Using tags with SVN
Posted by David Weintraub <qa...@gmail.com>.
On Fri, Apr 1, 2011 at 8:52 AM, Stirnweiss, Siegmund SZ/HZA-ZIT3
<st...@schaeffler.com> wrote:
>> Now, there's nothing in Subversion preventing you from attaching a tag
>> to a particular version of a file. You simply copy files to the tag
>> directory one at a time. When a file gets approved, you "tag" it. It's
>> not the standard way to do it, but I've seen shops that do.
>
> What exactly do you mean with copy? Do you mean a "svn copy"? Or do you
> mean a file system copy?
In Subversion, there is no such thing as a special meta-data that
marks branches or tags as CVS has. Instead, you merely use directories
to mark branches and tags. This isn't all that unusual. Perforce
(another popular version control system) also uses directories for
branching and they call it "Interfile-branching".
For those who are use to branches being more than mere directory
structures, this seems strange. After all, what's the difference
between a directory in a module and a branch in Subversion? Then
again, what's the difference between a module and a directory in CVS?
Both merely use user conventions to maintain a structure that doesn't
exist in the underlying software.
And, Subversion's branching system work. I first ran into using
directories for branching with Perforce (another popular version
control system). Perforce called it "Interfile-branching". The
developers actually found it much easier to work with than the CVS
method of doing branches.
Branches were no longer mysterious piece of meta-data that remained
hidden. Instead, they were visible and easy to see. In CVS, to find
the names of all branches ever used in your project, you'll have to do
a "cvs log" on all the files in your module, and then grep out the
branch names and sort through them. In Subversion and Perforce, you
merely have to list the branch names as you would a directory.
In Subversion, the custom is to create three directories called
"tags", "branches", and "trunk". The "branches" directory stores all
of your branches, and the "tags" directory is for your tags. The
"trunk" directory is for your mainline development much like the
"trunk" in CVS is for. Some people put these on the root of the
repository, others put them in the root of the module.
Let's say I do my development on "trunk", and I want to make a branch,
in Subversion I would simply make a copy:
svn cp -m"Making branch 'foo'" http://svn/repository/module/trunk
http://svn/repository/module/branches/foo
In Subversion, the standard way of doing development is to do your
mainline development work on "trunk", then when you're work is either
feature complete, or you're ready to do a code freeze, you create a
release branch:
svn cp -m"Making branch for release 1.2"
http//svn/repository/module/trunk
http://svn/repository/module/branches/1.2
This allows some of the developers to continue working on the release
while others work on future development.
Once all the work is complete for Release 1.2 on the Release 1.2
branch, you can create a tag:
svn cp -m"Tagging release REL-1.2"
http://svn/repository/module/branches/1.2
http://svn/repository/module/tags/REL-1.2
There is nothing in Subversion that prevents you from creating an
"approved" branch or tag and allowing you to copy individual files to
that branch or tag when they are approved.
Let's say instead of merely creating a "trunk", "tags", and "branches"
directory, you create a "trunk", "tags", "branches" and
"approved-files" directory. The "approved-files" directory are the
files that have been approved for each release. (Notice I didn't
specify if "approve-files" is a tag or a branch. It doesn't make any
difference)
svn cp -m"Approved file foo.java"
http://svn/repository/module/branches/1.2/src/main/java/foo.java
http://svn/repository/module/approved-files/1.2/src/main/java/foo.java
Now, you can actually see what files have been approved and what files
have not yet been approved by merely listing the files on each branch:
$ svn ls -R http://svn/repository/module/branches/1.2 #All files
$ svn ls -R http://svn/repository/module/approved-files/1.2
#Approved files
Of course, if you insist on doing things exactly the same way you do
in CVS, there's nothing in Subversion that's stopping you. The below
is how I tag a particular file in "trunk" with the "Q" tag:
$ cvs rtag -l -m"This is how we approve file foo.java in CVS" Q
module/trunk/src/java/foo.java
$ svn cp -R -m"Approved file foo.java just like we do in CVS"
http://svn/repository/module/trunk/src/main/java/foo.java
http://svn/repository/module/tags/Q/src/main/java/foo.java
And, to build off the "Q" tag, you simply do a checkout just like
you'd do in CVS:
$ cvs co -rQ module
$ svn co http://svn/repository/module/tags/Q
And, if you need to "move" the tag "Q", simply copy the replacement
file to the "Q" tag:
$ cvs rtag -F -r1.2.2.3.1.2 -l -m"Revision 1.2.2.3.1.2 of foo.java
has been approved" Q module/main/java/foo.java
$ svn copy -r2339 -m"Revision #2339 of 'foo.java" has been
approved" http://svn/repository/module/trunk/main/java/foo.java
http://svn/repository/module/tags/Q/src/main/java/foo.java
In fact, Subversion has a big advantage over CVS if you insist on
doing this. In Subversion, you can get the history of the changes to
your "Q" tag:
$ svn log http://svn/repository/module/tags/Q/src/main/java/foo.java
This wil list all of the revisions ever tagged as "Q" for "foo.java".
It will list the dates when that tag was applied, who applied that
tag, and their comment. There's no way to do this in standard CVS.
--
David Weintraub
qazwart@gmail.com
RE: Using tags with SVN
Posted by "Stirnweiss, Siegmund SZ/HZA-ZIT3" <st...@schaeffler.com>.
> From: David Weintraub [mailto:qazwart@gmail.com]
> Sent: Freitag, 1. April 2011 02:14
> To: Stirnweiss, Siegmund SZ/HZA-ZIT3
> Cc: users@subversion.apache.org
> Subject: Re: Using tags with SVN
> On Thu, Mar 31, 2011 at 12:31 PM, Stirnweiss, Siegmund SZ/HZA-ZIT3
> <st...@schaeffler.com> wrote:
> > Hello,
> >
> > I'm currently thinking about migrating from CVS to SVN, since SVN is
said to
> > be the successor of CVS.
> >
> > When analyzing the differences between CVS and SVN I found tags are
treated
> > in a different way in SVN, than they were treated in CVS, because
the tag
> > concept in SVN is: A tag is just a "snapshot" of a project in time.
> Tags are suppose to be "snapshots" of a particular version of the
> application.
Exactly, in svn tags are a snapshot of the application, in cvs a tag on
a file is what it is called: a tag.
> Sometimes you can adjust a tag if you've tagged the wrong
> file, but that should be fairly rare. In Subversion, tags take less
> than a second to do while in CVS, you have to tag each and every file.
> Long files have to be rewritten after every tag. That, to me is a
> great advantage in Subversion.
Having to tag each and every file in cvs for us is a feature. It helps
us achieving our goal in a very convenient way.
> > We use tags in CVS to identify the files which have passed module
tests and
> > should make it into our integration test environment. When they have
passed
> > the integration tests we use a different tag to identify the files,
which
> > make up the software in/for our production environment. In addition
to that
> > our development model is not release driven. As a result we do not
tag the
> > HEAD of our complete source tree at a particular point in time.
> Whoa! That's dangerous. When you pick and choose tags, you may end up
> tagging the wrong file. Then, this is a CM error and not a developer
> error. That means the Finger o' Blame points to you and not to the
> developer who gave you the wrong file or forgot a file. You want that
> Finger o' Blame pointing not at you.
That's not the problem here. The developers themselves tag files and we
have not yet had a problem with this approach.
> I just came to my current position a couple of months ago, and that's
> exactly what we were doing. Tagging particular files, and then
> attempting to build from that tag. I put an immediate stop to that. We
> build on the head of the branches now. That has eliminated about half
> of our build errors and deployments go much smoother.
> Now, there's nothing in Subversion preventing you from attaching a tag
> to a particular version of a file. You simply copy files to the tag
> directory one at a time. When a file gets approved, you "tag" it. It's
> not the standard way to do it, but I've seen shops that do.
What exactly do you mean with copy? Do you mean a "svn copy"? Or do you
mean a file system copy?
> Even better, Subversion tracks when things were tagged and branched.
> In CVS, you have no idea when a tag or a branch was created and
> applied.
Exactly, I also came across that. And I think that's very valuable
information.
Thanks, Siggi.