David Woodhouse <[email protected]> said:
> On Thu, 2003-03-13 at 01:03, Horst von Brand wrote:
[...]
> > Wrong. Edit a header adding a new type T. Later change an existing file
> > that already includes said header to use T. Change a function, fix most
> > uses. Find a wrong usage later and fix it separately. Change something, fix
> > its Documentation/ later. Note how you can come up with dependent changes
> > that _can't_ be detected automatically.
> True. And this is the main reason I hate BitKeeper. I really don't give
> a rat's arse about the licence -- but I object strongly to the way it
> enforces a false ordering of changesets.
The dependency among changes is a partial order, the sequence in which they
were applied is one valid topological sort of that, and the only valid one
known to the SCM. Asking the user to provide the complete dependencies is
error prone at very best.
> Assuming no ordering is wrong. But likewise, assuming the order in which
> changes _happened_ to occur is also wrong,
But much less so.
> and _enforcing_ that is more
> wrong.
What else can you do?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Sat, Mar 15, 2003 at 10:17:23AM -0400, Horst von Brand wrote:
> David Woodhouse <[email protected]> said:
> > On Thu, 2003-03-13 at 01:03, Horst von Brand wrote:
>
> [...]
>
> > > Wrong. Edit a header adding a new type T. Later change an existing file
> > > that already includes said header to use T. Change a function, fix most
> > > uses. Find a wrong usage later and fix it separately. Change something, fix
> > > its Documentation/ later. Note how you can come up with dependent changes
> > > that _can't_ be detected automatically.
>
> > True. And this is the main reason I hate BitKeeper. I really don't give
> > a rat's arse about the licence -- but I object strongly to the way it
> > enforces a false ordering of changesets.
>
> The dependency among changes is a partial order, the sequence in which they
> were applied is one valid topological sort of that, and the only valid one
> known to the SCM. Asking the user to provide the complete dependencies is
> error prone at very best.
No kidding. BK is draconian about it and that makes it work for the naive
users but the really smart ones have to work around the restriction.
Arch is closer to what you want, it allows out of order changesets. You'll
find problems with that as well, in fact, a lot of problems, but it is
what you guys _say_ you want.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Sat, 2003-03-15 at 14:17, Horst von Brand wrote:
> The dependency among changes is a partial order, the sequence in which they
> were applied is one valid topological sort of that, and the only valid one
> known to the SCM. Asking the user to provide the complete dependencies is
> error prone at very best.
>
> > Assuming no ordering is wrong. But likewise, assuming the order in which
> > changes _happened_ to occur is also wrong,
>
> But much less so.
>
> > and _enforcing_ that is more
> > wrong.
>
> What else can you do?
You could at least allow changesets to be committed out-of-order if they
don't touch the same files _at_ _all_. Unless you're going to do a
complete compile-and-regression test after every commit, you have no
business being anal about change ordering either.
I don't claim this is _easy_, merely that it's a requirement for me to
be happy with the thing.
I also _really_ miss the ability to 'pull' while there are uncommitted
changes in the checked-out tree. Especially since actually having
_committed_ certain one-line compile fixes makes all my _real_ changes
depend on them, etc...
--
dwmw2