On czwartek 13 marzec 2003 02:17 pm, John Levon wrote: > On Thu, Mar 13, 2003 at 02:12:07PM -0500, Kuba Ober wrote: > > I was very explicit about things. First of all, if you are wearing all > > the hats yourself -- you're a developer, reviewer and administrator of > > the project, the only thing you need to do to make a new change and > > integrate it to the master server is: > > This is about 10 lines too long. > > > $ ae_p lyx.1.4.1 > > # once per login, and only if there are many projects; the msot recent > > branch of the first project is a default > > what is a login ?
Your unix login, as in logged in to the terminal. ae_p is an alias for export AEGIS_PROJECT="$1"; > > $ tkaenc > > # a gui pops up and lets you type a change information > > Waste of time - gets in my way. Maybe I don't even know what I'm going > to do. 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. > > $ ae_c 110 > > # okay, we choose to work on change number 110 > > what on earth ... ? 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. > > $ aedb > > # begin development > > $ aecd; aecp README > > # add the README file into the change > > I seriously have to do this for every file I want to edit ? aedb = develop begin; you do it only to start development of a change, so it's done once per change 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 > > $ vi README > > # do the changes (you could use any editor, obviously) > > $ aed && aeb && aede > > # build and finish development -- note that build here will do nothing, > > as # compilation results are in the repository too [managed automatically > > # by Aegis] > > $ aerpass > > # make the review pass > > $ cd ~; aed && aeb && aeipass > > # build and integrate into the baseline for given branch > > I assume you can turn this stuff off. Well, first of all you're a developer. A developer's business is to mind his own business ;-). So, once you do your edits, aed = do the diffs against the baseline 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) aede = finish the development, the changes goes into "awaiting review" state aerpass = indicate that the change had passed the review, this has to be done by whomever is marked as a reviewer, obviously it can be the same person all the time cd ~ = well, you have to exit the development directory before integration, since after stuff is integrated the development directory will vanish aed = do the integration diffs aeb = do the integration build aeipass = indicate that the change has passed the integration, this has to be done by whomever is marked as project administrator; once the integration is done the change becomes part of the baseline One should think of each change as a separate branch in the CVS model. Actually, a branch is just a regular change with a flag set indicating that it's a branch, not just "any" change. Changes can be bounced back and forth between the following states: awaiting development (say a new automatic change entry via bugzilla, or manually via tkaenc) being developed awaiting review awaiting integration being integrated completed. Only the "completed" state is final -- once it's integrated, it's integrated ;-) One of significant drawbacks of CVS is that it effectively prevents you from sharing your work in progress -- the only way for things to get to the "public" CVS server is via committing. Or you have to manually send diffs to 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 like in CVS where you can destroy the HEAD all you fancy and CVS is none the wiser). Cheers, Kuba Ober
