use case question

[Phil Lawrence <pr...@Lehigh.EDU>]

I'm trying to design our usage of svn...   We'll be tracking a  
repository of code that gets along with a vendor-provided product.

As long as we're using VEN6 (version 6 of the vendor product),  
everything is pretty straightforward.  Note that we do NOT put the  
vendor code into our repository.

Example:
   Change the frabblewizzit, as per issue tracker #656
   $ svn copy $SVN/ven/trunk $SVN/ven/branches/656 -m "Creating  
branch for issue #656"
   $ svn co $SVN/ven/branches/656/.../frabbles ~/Dev/656
   ...  do some work  ...
   $ svn commit ~/Dev/656
   $ svn merge -rnnn:nnn ~/Dev/656 $SVN/ven/trunk

But what about when VEN7 arrives?  We can create a VEN7 branch from  
our current HEAD, and work for a while on that branch to get it to  
work with the new vendor software.

But, what would we do with the frabblewizzit example?  Do we merge  
branch 656 -> HEAD and then merge the HEAD change into the VEN7 branch?

Or do we wait until VEN7 is pretty stable, and then merge the  
changeset of all the recent HEAD revisions into the VEN7 branch, and  
then continue to merge all HEAD revisions into VEN7 as they happen?   
And then finally merge VEN7 somehow back into HEAD when we upgrade?

Or do we not merge *anything* from HEAD into VEN7 and just merge VEN7  
into HEAD when we're ready for the upgrade?

Thanks,
Phil
  

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: use case question

[Gábor Szabó <sz...@gmail.com>]

On 7/8/05, Joshua Varner <jl...@gmail.com> wrote:
> On 7/8/05, Phil Lawrence <pr...@lehigh.edu> wrote:

> Typically long-lived branches (like the VEN7 branch) would have the
> trunk merged into them periodically so that they stay in sync, thus
> minimizing the changes when VEN7 is merged back into the trunk.

The drawback of long lived branches and frequent merges from trunk is that 
you have to track all the merges you did as Subversion does not do it for you.

In your case though as I understand there is no actual development done on trunk
but you have distinct branches for each issue (e.g. 656) and you merge
them to trunk
one-by-one as they are ready.

I think I would take the same branches (e.g. 656) and merge them to
VEN7 as well.
This way it is actually easier to keep track of the merges.
When you decide that VEN7 is stable you already have all the changes
that went into trunk. you can them move trunk to be VEN6 (or remove it
altogether)
and VEN7 to be trunk.

Gabor

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: use case question

[Joshua Varner <jl...@gmail.com>]

On 7/8/05, Phil Lawrence <pr...@lehigh.edu> wrote:
> But what about when VEN7 arrives?  We can create a VEN7 branch from
> our current HEAD, and work for a while on that branch to get it to
> work with the new vendor software.
> 
> But, what would we do with the frabblewizzit example?  Do we merge
> branch 656 -> HEAD and then merge the HEAD change into the VEN7 branch?
> 
> Or do we wait until VEN7 is pretty stable, and then merge the
> changeset of all the recent HEAD revisions into the VEN7 branch, and
> then continue to merge all HEAD revisions into VEN7 as they happen?
> And then finally merge VEN7 somehow back into HEAD when we upgrade?
> 
> Or do we not merge *anything* from HEAD into VEN7 and just merge VEN7
> into HEAD when we're ready for the upgrade?
> 
Typically long-lived branches (like the VEN7 branch) would have the
trunk merged into them periodically so that they stay in sync, thus
minimizing the changes when VEN7 is merged back into the trunk.

So for branches like 656 which are made for short term work, they
would be made from and merged back to the trunk. Then those changes
would then be propagated to VEN7 at the next merge from the trunk.

see http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.4.2
for more detail.
Josh

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org