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

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

Vladimir Prus wrote:
> Robert Ramey wrote:
>
>> Its A LOT LESS work for the developer.  Under the current  (old)
>> system every time a test failed I would have to investigate whether
>> it was due to an error new error in my library or some change/error
>> in something that the library depended up.  It consumed waaaaay too
>> much time.  I gave up commiting changes except on a very infrequent
>> basis.  Turns out
>> that the failures still occurred but I knew they weren't mine so I
>> could ignore them.  Bottom line - testing was a huge waste of time
>> providing
>> no value to a  library developer.
>
> A situation possible under proposed system is:
>
>        - You develop things on your branch. When your
>        feature is ready, you merge from trunk.

This you won't do.  If you merge into your own branch
it will be from the stable release.  You might want to
such a thing when a new release occurs - maybe
once a month or so.

Suppose that when you merge from the next release the
following occurs.
>        Suddenly
>        half of tests in your library fails. The merge brought
>        changes in about 100 different files,

Which indicates that either the other library changed its
interface - which it shouldn't do without advice.  Or that
your library was relying on undefined aspects of the
other library's interface - which you shouldn't do.  This
problem should occur much less frequently than it does
now.

> and you have  to figure out what's up.

Like you have to do ALL the time now.

> With the current system, you'd get a failure whenever the problematic
> change is checked in. So, you'll know what some commit between 1000
> and 1010 broke your library and it's easy to find out the offending
> commit  from that.

Not that easy.  As I've been checking in at the same time I still
have to look at modules in my own library as well as other libaries.
I need to know that if something breaks, its in my library and that
only one thing changed at a time.

> In other words, in the current system, if some other library breaks
> yours, you find about that immediately, and can take action. In the
> new system, you'll find about that only when your feature is done --
> which is more inconvenient.

Nope - its better.  If my changes pass all the tests against the
release version - I'm ok.  I merge into the stable release I'm sure
to pass - after all that's what I've been testing.  If someone else
merges something into the stable release - but my tests break
when I merge into my branch - then I know what it is and we
can arm wrestle with the right persone.

Basically using someone else's library to test your library
is not  great idea.  Its inefficient and not really effective.

>You can try to workaround this by
> frequently merging from trunk, but it won't quite work. Trunk
> receives bulk updates. So, if
> the other developer did 100 changes on this branch and merged, you'll
> only have the chance to test all those 100 changes when they are
> merged to trunk.

I don't think anyone should merge from the trunk ever.  Why
interject a bunch of experimental code into my project.  I have
my hands full just trying to find and fix my own errors.

Robert Ramey