Re: gratuitous changes

[Robert Anderson <rwa@alumni.princeton.edu>]

On Mon, 2003-02-03 at 07:09, Stefan Monnier wrote:
> > > 	Stefan "about 200 locally modified files"
> > PS.  You need a branch about 190 files ago. :)
> 
> A sandbox is in many ways a special extra-leightweight branch,
> and I do use it that way (I have a couple other sandboxes).

Sure.  But editing 200 files is a bit of a heavy lifting task for an
extra-lightweight branch without the features to control those kinds of
extensive changes.

> A real branch would have the advantage of making the code available to
> other people,

That's one advantage, but probably not the central one from my view. 
The central advantage is that I have serious doubts that your 200
changed files comprise one well-defined changeset that fixes bug X or
adds feature Y.  Even if it does implement some kind of large feature or
bugfix, I think if upon commit, a regression or crashing bug was
discovered, you would have quite a large number of possibilities of
where to look for the bug, and, the real problems with large-scale
development in a sandbox - no way of recreating the intermediate steps
you used to get to the code state that was committed.

If instead you had a branch, you could approach your tasks one at a time
without fear of disturbing other developers when it is time to check in
a tentative or intermediate logical changeset.

Why do logical changesets matter?

1)  Because they can be rolled back when bugs appear to isolate the
possible causes, creating ostensibly self-consistent code states at each
step, as opposed to rolling back a file and just hoping the changes in
that file don't depend on other changes in other files.

2) Because it is often the case that branch developers will want to
incorporate some changes from mainline or vice-versa in order to do
their own work more effectively, and doing so with logical changesets
has an order of magnitude less complexity than trying to do so an a
per-file basis.  Not to mention that CVS's complete lack of history
sensitivity for merging makes this a dangerous and confusing task from
the get-go - probably best avoided altogether, which is a shame.

 but requires more work when merging changes from the
> trunk, when committing changes to the trunk and it would be more
> difficult to get a meaningful summary of "what's changed w.r.t. the
> trunk" which I normally have all the time in my *cvs* buffer.

Right.  Because CVS branch support is abysmal, for no good reason other
than historical baggage.

> I guess there is something for CVS, Subversion, MetaCVS, Arch, OpenCM, ...
> to learn here, but I'm not sure what,

Seamless support for branches is central.  Arch, for one, nails this. 
(But neither is it demonstrably ready for prime-time deployment).

Stepping off soap box,
Bob