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

Re: Externals or vendor branches?

From: Jeroen Coumans <jeroen_at_jeroencoumans.nl>
Date: 2004-08-12 23:51:29 CEST

Keith Smith said the following on 12-08-2004 23:41:
> On Tue, 2004-08-10 at 23:35, Jeroen Coumans wrote:
>
>>This setup is working fine, but it doesn't scale well. For example, we
>>now have 20 branches. To merge upgrades from the trunk requires checking
>>out each branch and merging the changes. Apart from the diskspace
>>requirements and time spent on checking out & checking in, You can see
>>how this becomes an increasingly large operation as the number of
>>branches grows.
>
>
> I can't answer your specific question, but for my education, why do you
> find it necessary to have 20 branches? Do they represent slight
> variations on the same product for 20 different customers?

Yes, they do. We provide customized installations for an open source
product. For some customers, we modify the source a bit. Each has their
own specific installation (configuration, optional modules, hacks etc).
The product is regularly updated, so we use Subversion to merge updates,
share hacks etc. But the more customers (branches) we have, the tougher
it gets to keep each branch up-to-date with the trunk.

Most branches share 99% code with the trunk. However, we'd like to keep
the flexibility of maintaining hacks for branches only, while keeping
the merging as low as possible, eg. branches should automatically get
updated files except for customized files.

-- 
Groeten/Greetings,
Jeroen Coumans
www.jeroencoumans.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 12 23:51:52 2004

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.