On Monday, April 10, Pavel Roskin wrote:
> Hello, Tobias!
>
> > Why, this is a matter for branches, diffs, multiple "sandboxes", and some
> > tags (for the bigger projects). It really is quite simple. And to you
> > people that say "my sandbox is 100+MB, it's not practical, etc", I say
> > "have you looked at the price of disk lately!?!"
>
> So, you are suggesting "cvs checkin" as a way to move sources from one
> machine to another? That's interesting.
Nope, I'm saying that using 'cvs diff', and patch, most of this testing,
should the developer feel it is necessary, should be largely trivial to do.
There are changes that do not need a full-blown test, in order to pass muster.
Think of comment typo's, simple constant changes (ok, given a CPU specific
enough function, that may bite you as well, but you get the idea), etc.
Developers should be competent enough to realize which changes may get them
into trouble, and do a diff and patch on a another machine, in order to test
their changes...
> Could you explain this idea in more details? Suppose that developers A and
> B modify file test.c on machines M and N. Let's assume, for simplicity,
> that they modify different functions, so there should be no conflicts.
Conflicts are orthogonal to this issue. Conflicts get handled at commit
time. At least for the people using CVS without edit/locking stuff.
> The code is written and tested on M, checked in and then tested on N.
> There are branches "not_tested_on_N" and "tested_on_N". A commits on M to
> the branch "not_tested_on_N". B does the same. A updates on N and finds
> problems in the code that [s]he didn't modify!
Nah, code is written/tested on M. Developer thinks that N might blow, so
he/she does a 'cvs diff | ssh N patch', and tests on N as well. All is
well, he/she commits from M or N. 'cvs update' should handle things fine
on both boxes.
If there are bigger changes, then a branch may be a better idea (we're
talking reimplementation from C -> C++, or some other large change here).
> I don't want to commit my code that is not ready for "consumption" to any
> branch that other developers may have access to. Maybe you are suggesting
> personal branches?
Why not commit? If your teams goal is to produce working code, the changes
should always be ready for consumption. If the changes are too big, then
use a branch. Using other means (auto-builds, and some tags), the correctness
of various stages of the tree/branch can be kept under control...
--Toby.
