Re: A modest proposal -- We need a patch penguin

Geert Uytterhoeven
2002-01-30T20:53:57Z

On Wed, 30 Jan 2002, Larry McVoy wrote:

> > Er, not the pristine tree, the linuxppc_2_4 tree, sorry. I'll try
> > again. One of the problems we hit frequently is that we have to move
> > files from linuxppc_2_4_devel into linuxppc_2_4, once they prove stable.
> > But just creating a normal patch, or cp'ing the files means when we pull
> > linuxppc_2_4 back into linuxppc_2_4_devel we get a file conflict, and
> > have to move one of the files (the previously existing one) into the
> > deleted dir. How do we cleanly move just a few files from a child tree
> > into the parent? I think this is a lot like what would happen, if Linus
> > used BK and we wanted to send him support for some platforms, but not
> > all of the other changes we have.
>
> BitKeeper is like a distributed, replicated file system with atomic changes.
> That has certain advantages, much like a database. What you are asking
> violates the database rules, if I understand you properly. Are you asking
> to move part of a changeset? That's a no no, that's like moving the
> increment to your bank account without the decrement to mine; the banks
> frown on that :-)
>
> Or are you asking more about the out of order stuff, i.e., whole changesets
> are fine but not all of them.

If I understand it correctly, yes, you want to `push' only one changeset (the
creation of the new file) to the parent repository. Either directly (through
push), or through creating a patch in the child repository and importing it in
the parent repository.

[ Disclaimer: I'm not that familiar with the problem Tom mentions ]

However, why couldn't BK automatically resolve this?

In BK, a file creation (or a rename) is simply a changeset, just like a change
to the contents of a file (i.e. a patch that affects one file only), right?

If I modify a file in the child repository, and that change ends up in the
same file in the parent repository (i.e. Linus applied the patch I sent there),
BK will automatically resolve the issue when I do a pull in my child
repository. How is this different from a new file I added in the child
repository, and the same file (with the same contents, or contents from a
previous revision in the child repository) that got added in the parent later?
If I do a pull, BK should `merge' the change (a new file)? Or am I missing
something?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds