From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-08-02 12:51:20
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. Suddenly
half of tests in your library fails. The merge brought
changes in about 100 different files, and you have
to figure out what's up.
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
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. 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.
> Don't even start on the effort trying to get a release out when everything
> is changing at once.
> And scaling. each boost release with one library added will basically
> be a pain in the neck for one developer and maybe the release manager
> (though not necessarily). Now its a pain in the neck for ALL developers
> at once.
> Robert Ramey
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk