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