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

Re: CVS and SVN: Tags and Branches.. A question of strategies

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: 2007-03-05 17:08:01 CET

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
Received on Mon Mar 5 22:16:47 2007

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.