On środa 12 marzec 2003 11:45 am, you wrote: > On Wed, Mar 12, 2003 at 11:42:40AM -0500, Kuba Ober wrote: > > I guess that one has to have an attitude of burning bridges behind > > oneself in order to really enjoy Aegis. I had the pleasure of not having > > a VCS at all in my development, and starting right on with Aegis. I > > imagine that the CVS legacy may hurt, since your previous experience sort > > of limits your field of view -- you don't see things that Aegis makes > > possible. I, for one, find that there's a ton of things that Aegis just > > does almost by itself, whereas CVS needs some scripting in order to do > > that. > > Liek what?
0. You don't operate on the "diff" level. You operate on change level. Changes are self-contained units, like database transactions. 1. You don't diff by hand, aegis does diffing of only the files in the change for you. 2. The changes have to compile and build against your change, and against the baseline. CVS doesn't care. With Aegis, you never get a change that breaks builds! 3. If you specify it in your change attributes, the tests will be automatically run, and the change will fail to integrate if the tests fail. You don't have to invoke anything by hand, other than the aegis build command itself. Aegis makes sure that before an integration, the chosen tests are successful. 4. You always work on the local repository. You can integrate with the "server" any time you want. The "main repository" doesn't break your development -- you can merge your change with changes to the repository as often or as rarely as you want. E.g. if you're working on a change in the "HEAD" branch, and HEAD changes, and you feel like doing another change, the changes will be isolated and you don't have to integrate or merge your previous change just in order to do a new, unrelated change. You control isolation level of your changes throughout the devleopment cycle, a mandatory merge will only be enforced before the actual build. 5. Branching is trivial and you don't need to worry much if you feel like branching -- just create a branch, that's it. You do it at home, your branch can be local, you can commit the branch to the server too. 6. Given proper diff/patch tools (say fhist), integrating development branches is a breeze, and the change model employed by Aegis makes sure that you won't break the build, even if you're cross-integrating several branches and changes, from several repositories. 7. It's very easy to share "unofficial" branches, within the same project framework, across developers, without having them committed to the "main" server. Any subset of repositories (remember, they are all and always local!) can have any subset of additional branches, there's no need for the "main" repository to be priviledged in any way in that respect. In fact, you can almost do anything you feel like without having any connection to the net. You can merge and integrate with "main" or any other server when and how you feel like. I guess these are the main advantages. Here's how an imaginary session changing one file in lyx tree looks on Aegis: # set the project to "HEAD" $ ae_p lyx.1.4 # new change (with a GUI!) $ tkaenc # choose to work on that change (say it's change number 45) $ ae_c 45 # go to the development directory $ aecd # let's edit the readme $ aecp README $ vi README # let's wrap it up -- first do the diffs (otherwise the build will ask you to do it), then do the build [note that the build will do nothing here!], and finish the development $ aed && aeb && aede $ aedist -send | mail [EMAIL PROTECTED] # now, let's have say John review that change, suppose he downloaded the change to a file called c44 $ cat c44 | aedist -receive $ ae_p lyx.1.4 # john lists changes, and will see that change 45 awaits review $ ael c $ ae_c 45 # John wants to see the diffs, quite often that's sufficient $ aed && aedless # John gives his thumb-up for the change $ aerpass $ aedist -send | mail [EMAIL PROTECTED] # okay, now it's up to Lars to do the integration -- let's say Lars gets the change from email as well -- email serves just as an example, these can go to the "main" repository automatically $ cat c44r | aedist -receive $ ae_p lyx.1.4 # Lars lists changes, and sees change 45 awaiting integration $ ael c $ ae_c 45diff # let's make sure the change is actually Lars-clean ;-) $ aed && aedless # okay, it seems there's enough C++ and STL in it ;-), let's begin the integration $ aeib # build and integrate $ aeb && aeipass And that's it. Including formal review with documented rejection capability (the change goes back to the developer then), and repository administrator's final look and integration. Power-users can have developer and administrator powers, for example, so that they can do a "full commit" (as in CVS) themselves. Lesser people, who are only developers, only do the development that lands in the main repository awaiting review, and then integration. Bugzilla can be easily integrated, so that confirmed bugs can automatically generate changes in "to be developed" state! Cheers, Kuba Ober
