> A few questions:
> - If I receive an Aegis changeset, how do I contextually eyeball
> its effects on the current repository? This is clearly
> something the kernel maintainers wish to do quickly and easily.
The aedist -receive command will create a work area and apply the
change set in the work area (the repository is in *no* way affected).
This performs a ``diff'' against the current project source, which
will show you the differences between the change sets and the
repository. (You choose the diff tool and options.)
So, so see the affect an incoming change set will have, run
show | aedist -receive
(to use the same example as the original posting).
If everything else is OK, it will be left in the "being reviewed" state.
How do you do this fast? Several ways:
1. for small change sets, this is pretty fast anyway
2. There is a -trojan option to aedist -receive. This says to stop
ofter the difference, without building or testing (just in case
there is a trojan). Now take a look, and abandon it if you don't
like it (or maybe repair it?). But you have to finish by hand,
it's a normal local change set after that.
3. set up a procmail filter or similar. You only need to look at
them once the machine has done the routine task of unpacking,
building, testing, etc. I'd want PGP authentication for this, though.
> - Is there support for forward branching? (right term?). Where a
> patch to a branched earlier release can be fed forward into
> the current. The Linux kernel isn't big/complex enough to
> need this, but it's nice for other stuff.
Yes, there is an "aeclone" command which replicates a change set
from one branch onto another. It flags file merges when they are
necessary.
> - If a change set has been committed to the main repository
> is it possible (easy) to see each of the individual changes
> which made up that changeset?
This is very loose use of terminology. Change sets are collections
of files (well, versions of files to be pedantic).
Aegis allows you to see the files and the versions of the files
that are (or were) in a change set.
Aegis treats branches as ``big change sets''. Literally, right
down into its internal data structures. You can see all of the
change sets which are combined to creat a branch, OR you can see
the cumulative set of files and the versions of the files that are
(or were) in the "big" change set that is (was) the branch. Both
views are possible. And you can have branches on your branches,
and they accumulate too.
> If so, can a single one of those be backed out?
Create a change set, checkout the file at an earlier version, commit
that change set (but, Aegis will want it to build and test OK,
before commit). Now the head of the branch has the file change reversed.
Similarly for larger collections of files. So, yes, you can back
out a change set or even a branch.
> - How does it implement the three-way merge? And what's your
> experience with the 3way merge? Does it work? I've always
> felt they're a bit scary.
Aegis has had 3-way merging for 8 years. It works fine. There is
a lot of opinion out there as to the best 3-way merge tool. Aegis
lets you use the tool of your choice - it simply provides the 3
files, and collects the result.
Regards
Peter Miller E-Mail: millerp@canb.auug.org.au
/\/\* WWW: http://www.canb.auug.org.au/~millerp/
Disclaimer: The opinions expressed here are personal and do not necessarily
reflect the opinion of my employer or the opinions of my colleagues.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/