> > > 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.
So how do you keep them isolated now?
>
> > > 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?
So, basically Q is your "stable" branch? You would merge that feature from trunk to Q. If you developed it in the feature branch you would merge the feature back to trunk and then merge that into Q. But, if you follow the unstable trunk pattern then you probably don't need feature branches.
>
> > 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.
No problem... once you understand tags in svn they really aren't that much different and you can answer all your questions.
BOb
Received on 2011-04-01 16:31:10 CEST