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

Re: Sparse Directories vs Externals

From: Robert P. J. Day <rpjday_at_crashcourse.ca>
Date: Tue, 24 Feb 2009 11:17:28 -0500 (EST)

On Tue, 24 Feb 2009, David Weintraub wrote:

> On Sun, Feb 22, 2009 at 11:14 AM, void pointer <rcdailey_at_gmail.com> wrote:
> > He states they are "error prone", however I was not able to get any details
> > on that out of him. I know in the past he has liked to work exclusively out
> > of a branch and simply merge over his changes to trunk whenever he completed
> > something (like a feature or bug fix), then delete his branch and recreate
> > it for the next thing and rinse and repeat.
> Already, I don't trust this co-worker. I bet he use to work with
> ClearCase.
> There are two theories on how development should be done.
> Method #1 -- the way your co-worker believes: You have two
> "streams", a development stream and an integration stream.
> Developers create their own independent development stream off of
> the integration stream, do their work, and then merge their changes
> back into the integration stream when completed. Advantages:
> Developers work in their own world that is unaffected by other
> developers. Disadvantage: Developers work in their own world that is
> unaffected by other developers.

  personally, i've recently become a real fan of anything beyond a
trivial fix being placed in its own branch until it's really and truly
*finished* and ready for merging, for a couple reasons.

  the first is that it's depressingly common for someone to commit
what they think is a complete feature. but, oops, they accidentally
committed something completely unrelated so another commit takes that
out. and, oops, they forgot to "svn add" that new header file so
there's another commit. and, oops, ... etc etc ... what should have
been a single, logically coherent commit turns into a number of oopsie
fixes, some of which leave the repository in a non-buildable state.

  the other reason is that, if you're working with Q/A people, and
they're trying to certify your software, any change to the code base
-- no matter how trivial -- invalidates all their work and they have
to start over. so you want to minimize all those picky little commits
to the trunk.

  anyway, just my $0.02.


Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.
http://crashcourse.ca                          Waterloo, Ontario, CANADA
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-24 17:19:09 CET

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.