Re: BitBucket: GPL-ed KitBeeper clone

Daniel Phillips (phillips@arcor.de)
Sat, 15 Mar 2003 22:25:54 +0100


On Sat 15 Mar 03 17:21, Horst von Brand wrote:
> Daniel Phillips <phillips@arcor.de> said:
> > On Thu 13 Mar 03 01:52, Horst von Brand wrote:
>
> [...]
>
> > > I don't think so. As the user sees it, a directory is mostly a
> > > convenient labeled container for files. You think in terms of moving
> > > files around, not destroying one and magically creating an exact copy
> > > elsewhere (even if mv(1) does exactly this in some cases). Also, this
> > > breaks up the operation "mv foo bar/baz" into _two_ changes, and this
> > > is wrong as the file loses its revision history.
> >
> > No, that's a single change to one directory object.
>
> mv some/where/foo bar/baz
>
> How is that _one_ change to _one_ directory object?

Oops, sorry, I didn't read your bar/baz correctly. Yes, it's two directory
objects, but it's only one file object, and the history (not including the
name changes) is attached to the file object, not the directory object. This
is implemented via an object id for each file object, something like an inode
number.

> > > > ...then this part gets much easier.
> > >
> > > ... by screwing it up. This is exactly one of the problems noted for
> > > CVS.
> >
> > CVS doesn't have directory objects.
>
> And it doesn't keep history across moves, as the only way it knows to move
> a file is destroying the original and creating a fresh copy.

Ah, but it does. Sorry for not explaining the object id thing earlier.

> > Does anybody have a convenient mailing list for this design discussion?
>
> Good idea to move this off LKML

Yup, but nobody has offered one yet, so...

Regards,

Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/