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
lesmikesell_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1221958
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-24 20:00:05 CET