Re: BitBucket: GPL-ed KitBeeper clone

Werner Almesberger (wa@almesberger.net)
Thu, 13 Mar 2003 00:11:09 -0300


Daniel Phillips wrote:
> Naming is a matter of taste, and you ought to be able to do it according to
> your own taste, including hooking in your own name-generating script.

Yup, what I mean is that the system shouldn't have to depend on a
human-usable name. It's usually very hard to generate unique names
that are also human-friendly, so I think it's better not to try in
the first place. (Just look at e-mail message-ids for an example.)

> > I think, for simplicity, changesets should just carry their history
> > with them. This can later be compressed, e.g. by omitting items
> > before major convergence points (releases), by using automatically
> > generated reference points, or simply by fetching additional
> > information from a repository if needed (hairy).
>
> I would not call that hairy, it sounds more like fun.

I called it hairy, because you need to retrieve something from a
machine that may not be available at that time. Waiting until it
comes back usually isn't a choice. Of course, this information
may be replicated on other machines that are available, and that
your repository/agent knows of, etc.

In any case, this would be an optimization. Bandwidth and disk
space are cheap, so it's not so bad to carry a few kB of history
around for each file.

> getting the underlying framework to function properly. Larry is entirely
> correct in pointing out that it's hard, though in my opinion, not nearly as
> hard as kernel development. Your edit/compile/test cycle is a fraction as
> long for one thing.

Oh, I'd say it's an entirely different type of development. The
kernel has to deal with real-time concurrency and subtle
performance issues. An SCM can quite easily eliminate concurrency
to the point that all operations become nice, linear batch jobs
on a completely static data set. On the other hand, the SCM is
likely to work on more complex data structures, and will have a
closer interaction with what is user policy.

While performance is certainly an important issue for an SCM, I'd
expect this to be something that can be safely ignored for a good
while during development. (I'm a firm believer in the
prototype-burn-rewrite-burn_again-... type of software development.
Maybe this shows :-)

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
-
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/