[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: Les Mikesell <lesmikesell_at_gmail.com>
Date: Tue, 24 Feb 2009 12:58:31 -0600

Robert P. J. Day wrote:

> 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.

But isn't it better to find this stuff out daily and fix the small
pieces rather than have different developers wasting weeks of work on
those conflicting changes?

> 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.

The handoff should be through tag copies or revision numbers. It
doesn't matter what happens in newer revs - they won't access them until
you tell them to go to the next tag or release revision. It doesn't
make any sense for QA to be looking at trunk/head - that's not a
reproducible state by definition.

   Les Mikesell
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-24 20:00:05 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.