[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Using tags with SVN

From: Stirnweiss, Siegmund SZ/HZA-ZIT3 <stirnseg_at_schaeffler.com>
Date: Fri, 1 Apr 2011 14:29:31 +0200

> From: Bob Archer [mailto:Bob.Archer_at_amsi.com]
> Sent: Donnerstag, 31. März 2011 20:50
> To: Stirnweiss, Siegmund SZ/HZA-ZIT3; users_at_subversion.apache.org
> Subject: RE: Using tags with SVN

> > 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.
> > This differs somewhat from the CVS concept of a tag: "You can use
> > the tag command to give a symbolic name to a certain revision of a
> > file."
> > We use tags in CVS to identify the files which have passed module
> > tests and should make it into our integration test environment.

> So you are saying you test "files" in isolation? That seems a bit unusual I think.

Sorry Bob, I was not precise concerning this point. "Isolation" here means, that the system where we test is not integrated with other systems. And, yes, the files are tested together with the rest of the files from the cvs head.

> In svn you use a "tag" to give a symbolic name to a certain revision also. It's really not all that different.

Yes, you are right. The difference is, that e.g. the "Q" tag is shifted further when a new feature added to the file shall be tested in the QA environment, which is fully integrated. The features I'm talking of are quite fine grained. Due to that it would lead to lots of branches, if we used a branch for each of them.

> > 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. As soon as we
> > have finished development of a feature or functionality we tag the
> > files which have been changed with a tag named "Q". In a different
> > workspace we check out the "Q" tagged source tree. This gives us
> > the possibility to go on developing a feature while doing the
> > integration test on a previous revision of it and have a source
> > tree which consists of files, which reached the state of being
> > ready for integration tests or for production at different points
> > in time. In my opinion branches would be too complicated to achieve
> > the same functionality.
> > Does anyone have an idea how to achieve this flexibility and ease
> > of use with branches in SVN?

> What you described above is exactly what branches are for. Why do you think this would be complicated?

I'm quite new to svn, 'm not yet familiar with it and with the set of commands. Consider the following case: main development is done in trunk and in branches, perhaps. In order to provide a stable version of my files for testing it in my integrated environment I'm using a branch named "Q". A new feature is implemented by one of my colleagues. What would he have to do to get the files making up his new feature into the "Q" branch without losing its connection to the file in trunk?

> I think you are over thinking this... how is tagging a revision that contains the changes for a feature with a "Q" than tagging each file with a "Q"?

My apologies, my English is not that good to understand what you mean with this question.

Thanks, Siggi.
Received on 2011-04-01 14:30:18 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.