Re: Best Practice Question

On 09.05.06 17:06:16, Riesterer, Shawn (GE Indust, GE Fanuc) wrote:
> We used to use VSS and for this version of the software we moved to
> Subversion. So this is the first time we are encountering this
> situation in Subversion. I was wondering, what are the best practices
> for handling this? I figure we have to perform some kind of branch of
> the Trunk to do this, but I'm not sure what the best way is to handle
> both branches.

Well, I believe your use case is documented in the subversion book,
start reading here:

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html
  
> 1.) Branch the Trunk for the 2.0, making all the changes to 2.0 here
> and keep the Trunk running as 1.0.
>
> a. How do we handle changes that go into the Trunk for v1.0 that
> need to get in the 2.0 branch right away? Do we make them in both spots
> (which could be bad when merging the branch into the trunk after 1.0 is
> released)? Do we do weekly merges of the trunk to the branch (making
> sure to exclude those revisions when merging back from the branch to the
> trunk after v1.0 is released)?
>
> 2.) Branch the Trunk for 1.0, making all the changes to 1.0 here and
> in the Trunk and run the Trunk as 2.0.

I think 2) is more common, as "trunk" means something like: the newest
stuff you can get, the most bugs, the most features ;-)

As far as merging goes, if you change something in 1.0 and that change
needs to be in 2.0 too, you basically go into a working copy of your
trunk and do something along the lines:

svn merge -r 134:135 http:/subversion/branches/1.0/somedir/importantfile

This would merge anything that happend to "importantfile" between the
revisions 134 and 135. So the numbers need to match the revisions before
and after the change was commited. For more detail look into the book.

 
> Are there any other options?
 
Well in theory you could create 2 branches, for 1.0 and 2.0 and forget
all about trunk. But that doesn't make too much sense ;-)
 
> Also, how does this affect binary files? We have large number VB6
> applications which contain a lot of .FRX files. Performing a lot of
> merges could be very bad for these. Option number 2 seems to be less of
> a problem for these binary files, but could still have problems. Also,
> it seems odd to me to be tagging a Branch for the different builds and
> for the final version of 1.0.

Not sure what you mean, if the binary files changed they will be merged
if not, they won't. If the change is only in the binary data but not the
"data it represents" (I guess frx are some user interfaces?) this
shouldn't make a difference.

Andreas

-- 
You're growing out of some of your problems, but there are others that
you're growing into.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org