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

Re: Source migration

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-08-22 05:10:36 CEST

"McDonnell, David" <dmcdonnell@csu.edu.au> writes:

> /project/trunk/
> -> main development line
> /project/migration/
> /qa/ - qa branch that is checked out to qa enviroment
> /prod/ - prod branch checked out to production
>
> And to migrate a file you would just "svn copy" it from /project/trunk
> to /project/migration/qa/ or /project/migration/prod/ depending on where
> you wanted to migrate it to.

I'm not sure why you need to explicitly copy things.

Your process sounds odd to me -- is it really individual *files* that
get promoted from one branch to another? Or is it *changesets* that
get promoted? The latter is the more common case.

For example, someone fixes a bug in the devel branch. The change is
then 'ported' (via 'svn merge') to the qa branch for testing. If
it's all good, the change is then applied to the production branch.

So if that's what you're talking about, this is just a matter of doing
merges from branch to branch. Very common stuff.

If you're really talking individual file promotion, then yeah, sure, I
guess you can manually copy them around. As Francois said, you can
just run 'svn copy URL1 URL2.' No need for working copies. But this
case seems odd to me. Version control is usually about managing sets
of changes, not about juggling individual files.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 22 05:15:38 2003

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.