[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] self-contained changesets?
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] self-contained changesets? |
Date: |
Sat, 27 Sep 2003 13:19:10 -0700 (PDT) |
> From: Joshua Haberman <address@hidden>
> Arch seems to require that anyone who wants to make their personal
> changes available to the world have access to a publically available
> server to host their personal archive. Is this a safe assumption?
Mostly I think it is -- but that doesn't mean that it isn't worth
providing support for when the assumption is false. It's also not
quite the case that arch requires that -- although the ways in which
it doesn't require it should probably be made more featureful.
Would you agree that email and netnews provide the other two most
obvious transports?
A simple thing is that you can, of course, pack up changesets to send
via such transports. Currently, encoding a tar bundle of a changeset
is the way to do that --- certainly (as has been often discussed) a
fancier encoding would be welcome.
A more complex idea is to allow some degree of archive mirroring over
those transports: monotone has been exploring this design space a bit
-- I think the idea can fit cleanly into arch.
> Also, for the case where someone wants to make small changes to an
> arch-versioned tree, the process of creating an archive, branching, and
> publishing the archive seems like overkill.
Simply packing up a changeset and mailing that works just fine.
Again, a "prettier" format for emailing changesets is desirable.
> Is it possible to implement a command similar in spirit to "cvs diff?"
> What I mean is that such a command would produce a self-contained
> changeset that doesn't have to be part of an archive, that could then be
> sent independently (say, as an attachment to email). Such as changeset
> would ideally apply as cleanly as possible even if the branch from which
> it was generated changed in the meantime.
See:
% tla mkpatch -H
% tla revdelta -H
% tla get-patch -H
% tla dopatch -H
and, of course there's always:
% info diff
% info patch
:-)
> In other words, I want to be able to generate an independent changeset
> against a tree that I can apply at any point in the future to that
> branch or its ancestors and have tla "do the right thing."
-t