On czwartek 13 marzec 2003 02:50 pm, John Levon wrote: > On Thu, Mar 13, 2003 at 02:40:31PM -0500, Kuba Ober wrote: > > Your unix login, as in logged in to the terminal. ae_p is an alias for > > export AEGIS_PROJECT="$1"; > > Oh that's OK then. > > > That's the whole thing. It's hard to do clean and nice development if you > > cannot say what you do. You can always modify it before final > > integration. > > I assume there's a non-gui form. Why is this better than ChangeLog ?
Non-gui form is there too. It just brings vi with a template. ChangeLog is actually generated for you, automatically ;-). As well as the TODO list. It's called list of changes, and you bring it up at any time simply by: $ ael c as in "AEgisList Changes" > > Well, each change that you create with aenc or tkaenc gets a number. > > Usually, there should be a change for each confirmed bug report at least. > > The job of creating changes is quite separate from the job of actually > > developing the changes. You can have different people doing creation of > > the changes, and different ones doing development. > > Isn't the computer the one that's good with numbers ? Well, change numbers are similar to bugzilla bug numbers. You always can list them to find out what the number is. And you choose current change to work on (you can have several under development at any time). > > aecd = change directory; it simply changes the current working directory > > to the root directory of the current change's (each change has its own > > development directory), obviously if you feel like doing cd > > ~/lyx.1.4.1.C110 instead of aecd, you're free ;-) > > > > aecp README = well, you have to be explicit which files are in the > > change; by default you either have a development directory symlinked to a > > read-only baseline, or you have a VPATH environment; either way you have > > to create physical files that you're gonna edit in your development > > directory; that's what aecp is for -- it copies the file from the > > baseline to the development directory > > Well this is no good at all. It's far too much administration. What if > I'm doing some work that requires some other changes that don't actually > form part of the change ? (For example, I'm fixing a NO_NEXT case - I > want to commit the fix but not commit the NO_NEXT turning on). Well, it's up to you to create all those separate changes. I find that the whole process if I need to do a one-liner kind of fix is about 2 minutes, from beginning to the end (change creation to final integration). > At the very least I need a full source tree available directly that I > can play around in. Sure. It is there. Your development three is symlinked to the baseline. That's the default model. The baseline is read-only, though, so if you want to actually change a file, you just aecp it. > > aeb = build (only the files that you change will be rebuilt, other ones > > will be used from the baseline -- that means that you don't have to > > notoriously recompile everything) > > That's no different to now. If a header file changes then dependent > files must be rebuilt Sure. I mean, in the end aeb just invokes whatever build tool you use - qmake+make, make, cook, whatever. > > cd ~ = well, you have to exit the development directory before > > integration, since after stuff is integrated the development directory > > will vanish > > And if I want to see what I just did ? Integration is the final step where you actually decide that your change has been sucessfully built, it passed tests and review, and is ready to become part of the working product. Your work is done in the development directory during development. Usually development involves aecp'ing the files that you want to modify, doing the modification, building and debugging the thing, and finally deciding you're done and finishing the development with aede. Your change has then to pass review -- if you're authorized for reviewing changes, you can just type aerpass yourself, that's all. Integration is done *after* review, and typically it's administrators role. In CVS terms, consider change development the work you do on your own branch (with commits and everything), review a look by somebody at your "final" state of the branch, and integration the merging of the branch into the main trunk. > I could probably survive with a system like this if I was working (as > in: being paid) on something. But this sort of methodology does not > agree with the whole devel/stable split. And I guarantee you that you > find people just hacking around outside of this framework anyway. Actually, the whole design is such that physically the repository files are owned by aegis user and they are read-only. Note that the repository only consists of stuff that has been integrated, the metadata about changes, and any changes that await review/integration. The development directories are only on developers' machines. The whole devel/stable split is OK if you feel like having one. I, for one, like to do everything in "HEAD", but the HEAD itself is kept stable all the time. Aegis supports as many branches as you fancy, so you can easily have 1.3 branch and 1.4 branch just as it is right now. > > the mailing list. In the Aegis model, you only need to say that the > > development is done; it then awaits review and anyone can have a look at > > it from the main (public) server, only when the change gets integrated it > > actually affects the baseline (which is supposed to be always working, > > not > > Assuming this works properly, that would be very nice yes. That's actually at the core of Aegis model: the baseline, whether it's a baseline for the branch, or for the trunk, is always in a working (must pass tests), buildable state. Aegis itself doesn't allow you to integrate any change that doesn't build on all declared architectures, and that doesn't pass the tests. Obviously, you can dispense with the tests if you want, and you can only let aegis know about just a few architectures (whatever is there in the build farm or in the form of cross-compilers). And you can put ";true" as the final element of the build command so that even if the build fails, Aegis is tricked into thinking that everything is all right. So, initially, you can defeat all safety and just live at the same unsafe level as you did with CVS. But the functionality is there, and it's trivial to reenable things whenever you're ready to use them. You can live on the edge and just use the default "unspecified" architecture, so that the software is tested to build using default compiler on whatever host the Aegis happens to sit. But it's actually worth using the architecture facitilites, as in my case whenever I do aeb (AEgisBuild), it gets compiled under gcc 3.2.2 on RedHat, as well as on BCC5.5 on windows. And it all happens without me having to actually boot windows, nor anything (wine to the rescue). Aegis actually does all the bookkeeping to ensure that, given the tests that you wrote, the change doesn't break anything. And it always has to build. So, whatever breakage there is, it's not supposed to get all the way into the integration stage. Before you aede (end the development), it has to build and pass the tests. Before it is integrated, it has to pass the review. Again, for the integration the change is turned into a patch has to cleanly apply, build and test. So if somebody integrated incompatible changes in the meantime (between development end and integration begin), you have to resume development, aem (AEgisMerge) with the baseline, fix any conflicts (they get indicated very clearly in the sources, are greppable, and all that), build again and try your luck with integration. Basically, Aegis model means that every time you claim you're done with the development, your development tree is remerged to the baseline if need be, and the patches generated are against the latest baseline. So, there are no more "this patch doesn't apply" situations that everybody is so familiar with. And actually, Aegis can happily send status messages to the list whenever a change is created, its description is changed (think of change description as a changelog/todo in one), or change's status is changed (say "being developed" -> "awaiting review"). There's almost no administration going, apart from backups. I haven't changed anything in my site's aegis setup (nor in my project's config file) since the first time I set it up. It just works. And I upgraded Aegis three times or so in that year. Cheers, Kuba Ober
