> > It's just that if you work on one thing, it's beneficial even for your
> > own sake to have different explorations/fixes/enhancements/etc. done in
> > different
>
> I tell you what I'd like (my ideal interface). I do some work. Then I
> run readdifftool or something and I can do some action on each (set of)
> hunks. So I can mark *this* bit as being "Just a test", *that* bit as
> "fix bug in lastPos()", etc. After that I can carry on working and the
> *next* time I do it, all the diffs are against the /last/ time I ran
> the tool (or something else). Eventually I can choose to commit
> properly a changeset or some number of them.
So, you essentially feel like working on one tree all the time. I guess that
having a very powerful tool to let you have multiple trees available at the
same time is better.
First of all, it isn't always that patch hunks come out exactly they way you
want them to. You'd need to actually have a tool to be able to split hunks,
interactively, and assign some descriptions to them.
Well, in Aegis you almost do that, but in a slightly different way.
Say you're working on a thing. You decide to test something. You create a new
change for the test, and you can even completely trash the tree. It doesn't
matter. If the test is worth anything, you just finish development and get it
integrated. If it turns out to be useless or you just needed it for your own
temporary purposes, you simply do "aedbu; aencu" as in "DevelopBeginUndo;
NewChangeUndo" -- the change is withdrawn, no trace of it left.
Whereas, when you find a bug that your pending stuff uncovers, you simply make
a separate change for it. So, you work on something, you find a bug in
"lastPos()", you simply create a new change for it with one-line description
"fix the lastPos() bug", you modify relevant files, it tests and builds, and
you're done. If you want, you integrate that right away, and then in your
"primary" change that you worked on, you just do "aem" (Merge) -- the fix
that you integrated into the baseline will be intelligently merged into the
tree for your current change.
> It really is that simple.
In your case, you want:
- set up the development tree
- work on something
- something else pops up, work on that too
- there's some testing to do, put that in as well
- you end up with a big patch that you have to split by hand (or using some
tool)
In Aegis case, you do:
- set up a change
- work on something
- set up another change for something else that came up
- work on that something else, finish it quickly (minor thing), get it
integrated
- set up another change for some testing
- wreak havoc in any way you feel like
- either finish and integrate the tested out thing, or just discard it
- work more on your primary thing
- decide it's a good time to merge with your other bugfixes (and other
people's work, if any has been integrated in the meantime)
- work some more (maybe resolve the conflicts if there were any)
- wrap it up, do the integration
The thing is, that
1. Aegis keeps your different tasks separated in their own source trees
2. The source trees are symlinked to the baseline, so there's no wasted disk
space (there are other ways to do it as well, e.g. via VPATH)
3. The baseline for the trunk and for each branch consists of a full working
thing -- meaning that the full working thing is a compiled thing, and all
compilation results stay there -- it's managed by Aegis, actually
So, the overhead of creating a new change, editing one or two files, building
and integrating ("committing") is almost nil -- the fact that you have a new
change doesn't mean that *everything* is rebuilt. Since working compiled
files are part of the repository (although they are managed by Aegis and you
don't need to be concerned about them at all), building a new change involves
only whatever the dependency tool (make/cook) deems necessary to do due to
the files that you have actually changed -- no more, no less.
And the even better fact is that it's relatively easy to set things up so that
e.g. LyX would be built using different glibc versions (just specify it as
part of the architecture) -- that way developers using different
linux/glibc/whatever version's don't need to suffer long recompiles if all
they did is to change a few files. That speeds things up immensely in my
experience.
> I think it would actually be possible, with a little CVS Root tweaking
> etc., to build that on top of CVS. Lars gets his small (even tiny)
> patches whilst I get to build up a few hours of work without getting
> distracted.
Sometimes just wording whatever it is that you're supposedly doing, even in a
single sentence, may help you. Creating new changes is a fast process --
apart from typing the changelog entry (oh well, initially it can be blank)
and having Aegis put the symlinks in place, there's nothing more to it.
Oftentimes I had 5-6 different changes started and wrapped up in an hour. If
say I was working on the data display part of my app, and I found out some
deficiencies in my maths libraries, I would fix the libraries in a separate
change. And so on.
Aegis really enforces that what you do doesn't break things. Nobody needs
commits that won't build. Nobody needs commits that will fail the tests
(obviously, only some things are easily testable in an automated way, some
are not at all, but say reLyx is an ideal candidate for decent tests). And
you yourself quite often do different things, so why on earth do them on the
same tree and risk destroying your other work? Change isolation is a real
benefit, once you start using it and get the feel of it.
> Aegis seems to do this, but its way too high an overhead in terms of
> type this, then that, then the other, it seems.
Okay, I've just checked it.
It's an overhead of about 5 seconds to create a change without description.
Note that this includes creating a buildable source tree for your use, and
the only disk space overhead is for the symlink inodes. I guess with tree of
LyX size, it may be more like 10 seconds, it may also depend on the
filesystem's speed.
It takes about 30 seconds to get a change that does nothing (say a punctuation
type in the README file) started, built, reviewed and integrated.
These are my own timings, initially I was a tad slower, but the commands are
very concise, most of them have no cryptic parameters to remember, the
documentation is very extensive (postscript printable docu and man pages).
The overall design of the commandline interface is developer-friendly. The
guy who did Aegis is not a masochist, you know ;-)
Cheers, Kuba Ober
