Re: Re: Maintaining 'stable' and 'development' versionsof a repository (hopeless newbie question)

| >  My personal opinion is that this is somewhat like putting people
| > in straightjackets to keep them from scratching their poison ivy
| > rashes. It's guaranteed to work, but ...
|
| I like things that are guaranteed to work, better than things that are
| not guaranteed to work. At least then I know where I stand ;)

 The problem with putting people in straightjackets is the side effects.

 The (theoretical) argument against the straightjacket goes something
like this:

 First, the version control system alone can't stop people from breaking
the code. (At best it can do it in cooperation with external tools, like
test suites that must pass before a change is comitted.)

 Second, the version control system can't actually stop people from
doing this; all it can do is stop them from doing it through the VCS
itself. This has the twin effects of withholding the VCS's official
endorsement (so people don't think 'the VCS allowed this so it must
be OK') and perhaps persuading (some) people not to do it because
it's sufficiently more difficult and awkward.

 Third, I think there's a lot of evidence that telling people not to do
this is swimming upstream. The 'one independant change after another in
one repository' style of development seems to be what people naturally
gravitate to until they're educated. (I think it's also the most natural
way to work with most VCSes given the current interfaces.)

 Fourth, even if you are working 'right' there are clearly situations
where what you're doing is naturally expressed as 'putting the same
change into multiple lines of development' (for example, a bugfix to
code that is the same across multiple LODs, although the LODs are
otherwise quite separate). And if you squint at it right, the perennial
issue of people wanting to 'compact' a long many-changeset line of
development into a single changeset for upstream is another variant of
this.

 Thus, given that people are going to do this anyways whether or not
the VCS supports them, it might as well help out where it can (with
appropriate warnings). The VCS is not making the situation worse by
helping: while people can break the tree by doing this, a) they can
break the tree through the VCS in other ways, and b) they can do this
anyways outside the VCS. By helping, the VCS has a chance to make the
situation better: it can help people avoid mistakes by automating things
for them, and it has a chance to raise warning flags about things that
look bad, and the VCS history itself can be more accurate so that even
when things go wrong, people can see more clearly how (and why).

 This isn't necessarily the right view for BitKeeper in specific; that
depends on what the companies using BitKeeper feel about the issue.
Since BK is used by a bunch of different companies, I suspect that if BK
ever adds features to support such a 'relaxed' dependancy model it will
make them a per-repository option, so some organizations can keep people
in the straightjackets they find necessary.

 Short of BitKeeper supporting this explicitly, it might be handy
if people wanted to write canned scripts to do this sort of patch
extraction and application. Canned scripts could make what people would
do anyways be more error-free, while helping people out by raising
warning signs if something seems problematic (eg trying to extract a
changeset and apply it to a tree that doesn't have the same starting
versions of the files involved).

        - cks, who wonders if anyone has ever defined a 'BitKeeper
               patch format' that captures moves and deletes for
               automatic application (he supposes you could just use
               the BK Changeset patch format and then ignore some of
               the information...)