Re: [boost] [SVN]Best Practices for developers using SVN

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-02 15:53:55

Vladimir Prus wrote:

> Okay, say somebody reports a bug in program_options that I fix
> (on a branch named program_options_one_line_fix_127).

> Say the same
> somebody reports a bug in a future library, and the author immediately
> fixes that (on a branch named future_one_line_fix_777). Now the user
> has to grab stable branch and perform two merges manually to get both
> fixes.

LOL - what does the user do now? I'm assuming that "user" refers
to someone who is using the latest (or previous) release.  This
user currently has seveal options:

a) work around the error until he downloads the next release (a year's wait)
b) patch his copy of the library.
c) Download the trunk and use that (assuming the bug is fixed there)

Under the new system he has the following options:

a) work around the error until he downloads the next release (a MONTH's 
wait)
b) patch his copy of the library.
c) If he want's he could sync up with the next release branch of the library
where the bug is fixed.  (personally I wouldn't do that).  This is easy if 
he's
using SVN "switch"

> Not to mention that if every one-line change is gated via release
> manager, it creates a bottleneck we don't presently have.

That one line change is now gated by the WHOLE release - 18 months
last time.

Now if by "user" you're referring to other library developers, they can
easily switch particular libraries to the development branch if they
want to coordinate with some other library. That is, in some
unusual situations, I could see c) above being useful.

>While it's good to be able to test specific branch, I doubt requiring
> all changes to be done on branch is so great idea.

Well, it doesn't look like we can require it.  But we don't really have
to.  Those who want to continue to check into the trunk and watch
the tests that occur there are free to continue to do so.  I suspect
that such tests will be even less useful in the future than than they
are now as more library developers move to this incremental
test/release scheme.

Note: I would propose a scheme for naming:

currently we have the "trunk" - OK its not relevant to me

we have something like "RC_1_34_0".  I would create a branch
off of this tag called "serialization_next_release".  When the time
comes, "serialization_next_release" can be merged into stable.
Then tagged with "serialization_1_35".  The branch
"serialization_next_release" would continue for the 1_36 version.
etc.

Robert Ramey