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

Re: [Fwd: Re: Branches? How many?]

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: 2007-05-10 15:31:28 CEST

Vandenbroucke Sander wrote:
>> Why the need for every developer to have a separate branch? Let all
> work
> It is mainly for the sake of backup. Once committed it is backup-ed.
> Otherwise there is a risk of loosing a great deal of work when a
> developers pc crashes.

Is it really necessary to isolate the developers from each other for
this work? If you branch for releases instead of development you will
always have a clean working instances in the release branch and it won't
matter if you have some temporary conflicts in the trunk. If developers
commit and update frequently in the trunk you'll get your backup and
they can take advantage of each others' changes instead of building up
large conflicts that have to be resolved later.

>> on the trunk and just use branch for releases and experimentell stuff.
>> After all having more than one developer work on the same code base is
>> what subversion is all about. If you need greater controll use a
> checkin
>> checkout model.
> What is this model?

That's where you lock files to avoid conflicts. It's only necessary if
your developers won't cooperate on changes with frequent updates. For
experimental versions or large distruptive changes you'll probably still
want a branch, but they shouldn't be necessary for small feature
additions unless you insist on always having a clean build in the trunk
(and there are sometimes reasons for doing that - you just have to
decide if it is worth the trouble in your case).

   Les Mikesell
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 10 15:32:00 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.