Changing the UI of checkout

[Stephen J. Turnbull]

Matthew D. Fuller writes:
 > On Mon, Apr 20, 2009 at 12:58:17AM +0900 I heard the voice of
 > Stephen J. Turnbull, and lo! it spake thus:
 > > 
 > > Of course you do.  As soon as you save a change, *you're out of
 > > sync*.
 > 
 > While philosophically apt, this is pragmatically nugatory.  And
 > philosophically, you don't take the point far enough.  Why give such
 > importance to the point where you save a change?  Why not when it's
 > made in your editor?  Why not when it's made in your head?  Why not
 > when it's conceptual, before translated into code?

"Save" is the operationally important instant because the VCS knows
about files on disk.  Not only does it know about them, but it *cares*
about them, and throws a fit if it doesn't like the contents.  It
doesn't care (or even know) about editor buffers, wetware buffers, or
the design preimage of The Code of Christmas Future.

 > In a practical sense, from the perspective of a VCS, anything that
 > happens before you commit is Not My Problem.

Eh?  What does "merge conflict" mean to you, then?  This may not be a
problem for your idealized workflow, as I understand it.  But
everybody who wants a workflow where the VCS supports concurrent
development is going to hear complaints from their VCS about it when
working (== developing and committing) in the checkout mode.

This is specifically true of the leading example in the tutorial of a
one-off fix by a downstream user.

 > > The whole idea of checkouts with "working trees" is ill-conceived.
 > > [...]  But anybody who makes changes to the code is putting
 > > themselves in harm's way by doing it in a checkout.
 > 
 > This is meaningless.  You can't commit WITHOUT a working tree.

My point is precisely that committing from a checkout is a bad idea,
because it's not guaranteed to succeed.  There are other uses for
checkouts that don't involve "working on" (== making changes to) them,
such as source trees for beta testing and release distribution.

 > > To protect your work, there should be a place to commit it. [...]
 > 
 > There is.  The branch connected to the working tree you're in.

Not if someone commits first from another checkout or bound branch.
Now you can't commit, even if there are no conflicts.  Worse, in order
to commit from the checkout you must damage the state of the checkout.

 > Your objection is that you don't want a workflow where there are
 > multiple working trees connected to a single branch.

Not quite.  I would be theoretically happy to have multiple working
trees if they were synchronized by a locking protocol.  This would
work fine for your use-case as you describe it, while providing a
guarantee that the VCS would not do anything to disturb your data.

Thing is, according to the discussion in this thread the whole point
of the current implementation of checkout is allowing one-branch,
multiple active working trees to happen.  Your use-case I have
sympathy for, but the implementation and generally accepted meaning of
"checkout" is not limited to it.

 > Which is fine; that workflow has implications significantly
 > different from one where there is only ever 1 working tree
 > connected to a given branch.  But just because you don't want those
 > properties doesn't mean other people don't.

I think I said that already.  I just think it's disingenuous of a
revision control system, which is supposed to preserve people's data
without getting in their way, to provide a facility that puts their
data at risk and simultaneously gets in their way, yet claim this is a
feature merely because it emulates primitive systems that have no way
to avoid these distressing events.