lkml.org 
[lkml]   [2003]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: BitBucket: GPL-ed KitBeeper clone
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:33    [W:3.916 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site