Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Wed, Mar 19, 2003 at 03:00:01PM +0100, Jean-Marc Lasgouttes wrote:
> You are lucky. I tried it with emacs-20.4/gnus-5.8.6, and it
> definitely did not work. What does this copiousoutput means, actually?
man mailcap
/copious
n
copiousoutput
This flag should be given whenever the interpreter
is capable of producing more than a few lines of
output on stdout, and does no interaction with the
user. If the mailcap entry specifies copiousout-
put, and pagination has been requested via the
"-p" command, then the output of the command being
executed will be piped through a pagination pro-
gram ("more" by default, but this can be overrid-
den with the METAMAIL_PAGER environment variable).
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Mon, Mar 17, 2003 at 09:46:04AM +, Jos? Matos wrote: >> This is what I have in .mailcap and that is relevant: >> application/x-gunzip; zcat; copiousoutput application/x-gzip; zcat; >> copiousoutput application/x-bzip2; bzcat; copiousoutput >> application/x-tar-gz; gunzip -c %s | tar -tf - ; copiousoutput John> Hmm, that works quite well, thanks john You are lucky. I tried it with emacs-20.4/gnus-5.8.6, and it definitely did not work. What does this copiousoutput means, actually? JMarc
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Mon, Mar 17, 2003 at 09:46:04AM +, Jos? Matos wrote: > This is what I have in .mailcap and that is relevant: > application/x-gunzip; zcat; copiousoutput > application/x-gzip; zcat; copiousoutput > application/x-bzip2; bzcat; copiousoutput > application/x-tar-gz; gunzip -c %s | tar -tf - ; copiousoutput Hmm, that works quite well, thanks john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Saturday 15 March 2003 17:43, John Levon wrote: > On Sat, Mar 15, 2003 at 11:50:28AM -0500, Kuba Ober wrote: > > That means you didn't configure your mail reader properly. It should be > > easy to do. What mail reader do you use? > > mutt Then you should follow André's advice. I use mutt and or kmail, for different purposes and I don't have any of the problems you refer to. This is what I have in .mailcap and that is relevant: application/x-gunzip; zcat; copiousoutput application/x-gzip; zcat; copiousoutput application/x-bzip2; bzcat; copiousoutput application/x-tar-gz; gunzip -c %s | tar -tf - ; copiousoutput > john -- José Abílio
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Sat, Mar 15, 2003 at 11:50:28AM -0500, Kuba Ober wrote: > That means you didn't configure your mail reader properly. It should be easy > to do. What mail reader do you use? mutt > But that's not the point. The point is that there's no reason methinks to have > patches sent via mail. As soon as a change is up for review, it's up for > review and then anybody who fancies may review it. I don't see a good reason to enforce some arbitrary difference between an individual looking at a patch and a discussion about the patch. john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
> > But why do you expect to be able to do everything in your mail reader? > > I expect to be able to read things I am sent in my mail reader. I expect > to able to pick out parts of patch and reply with them quoted saying > why I don't like the parts. I would like to able to do this without the > following process : > > Save the attachment > scp the file to my home box > gunzip the attachment > copy and paste all the relevant parts back to my mail reader > > Which is what I have to undergo now. That means you didn't configure your mail reader properly. It should be easy to do. What mail reader do you use? But that's not the point. The point is that there's no reason methinks to have patches sent via mail. As soon as a change is up for review, it's up for review and then anybody who fancies may review it. And even if a change is in the process, it's equally trivial to send the patch to the mailing list: cat `find . -type f \( -name "*,D" -o -name ".*,D" \) -print | sort` \ | mail -s My patch For whatever reason an alias for that doesn't come with Aegis, it's trivial enough to add one -- I have it, and it's called aedcat (compare to aedless and aedmore), and then it becomes aedcat | mail -s "Patch doing blah blah, comments anyone?" Cheers, Kuba Ober
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Fri, Mar 14, 2003 at 11:41:20AM -0500, Kuba Ober wrote: > I know that there are people who do everything in Emacs -- email, software Eww don't talk to me about emacs ;) > But why do you expect to be able to do everything in your mail reader? I expect to be able to read things I am sent in my mail reader. I expect to able to pick out parts of patch and reply with them quoted saying why I don't like the parts. I would like to able to do this without the following process : Save the attachment scp the file to my home box gunzip the attachment copy and paste all the relevant parts back to my mail reader Which is what I have to undergo now. > It makes about as much sense as complaining that you have to switch away from > your mail reader to play Quake. What does game playing and software > development management has to do with mail reading??? I don't know. But that's not what I'm doing. john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On piątek 14 marzec 2003 08:44 am, John Levon wrote: > On Fri, Mar 14, 2003 at 08:20:44AM -0500, Kuba Ober wrote: > > No matter how small or "insignificant" a change is, there should be a way > > to review it without having to post a patch to the mailing list. > > Sure - get the machinery to post patches. It's as easy in CVS as > anything else. > > > And the fact that a change either passed review or was rejected should be > > documented so that is accessible. > > We simply don't need formal machinery - the mailing list is good enough. I would argue. First of all, the mailing is *not* devoted only to patches. If we had lyx-patches list, that would make more sense. But apparently we don't. And then changes get lost in the noise, people forget them, it's hard to dig things up at times, and so on. That's because a mailing list is just that -- a mailing list. It has nothing to do with software development management. It can be abused for that purpose, but to me it doesn't make sense if there are good tools that were developed just for that purpose (actually, Aegis is a bit more than SCM). And a lot of the information in the mailing list is unaccessible without special tools, like archives, search-in-the-archive, etc. E.g. to see how a certain problem was attacked, what patches were submitted, and how it wound up, in Aegis you simply list the details of a change. Using a mailing list, if you don't actually read all the messages, you're depending on your luck, people's ability to use meaningful subjects, and your ability to formulate proper search terms in order to dig things out of the archive. I guess that's where you really have a lot of overhead to just see what was being done about a change, right? Obviously, one can and should still discuss things on the mailing list, it's just that with Aegis - you can refer to a particular change number, you don't have to repeat what the change is (you can put all the clean and nice description into the change, and then on the list you just send a mail with a subject "whaddya think of C094? -- and it's easy for everybody to look what's it about, without you having to repeat same thing in the changelog, on the list, etc.) - you have locality of reference -- if you're working on the repository, you have all your related information on hand, without even *having* to use your mail client [myself, I find it worthwhile shutting my KMail down as soon as I feel that I'm gonna spend more time reading the mailing lists than workin on a given day] - it's very easy to split a change into separate issues, if the discussion turns out to indicate that "it's really 3 different problems" - (note) even if somebody is on the windoze, there's the read only web interface to aegis, so you can always see what the change is all about -- so you're not forced to have a unix box available (locally or remotely) just to see what's going on I should also probably point out, that with Aegis the disk space and time overhead of trying out a thing three different ways on three different branches scales with the complexity of your change, and not with the complexity of the project. So if you have say 40 megs and a couple thousand inodes left on your filesystem, you could still create about two or three LyX changes, every of them in a different branch (say 1.2, 1.3 and 1.4) and compile them. Try that with CVS. Wish ya luck. Cheers, Kuba Ober
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On piątek 14 marzec 2003 08:46 am, John Levon wrote: > On Fri, Mar 14, 2003 at 08:36:10AM -0500, Kuba Ober wrote: > > Just imagine how much easier the life for Lars and all other potential > > reviewers would be, if instead of scouring the list for stuff to review, > > and everybody else complaining "my patch has been ignored, so here it is > > again > > Actually, context switching out of my mail reader just to review a > patch would be a major PITA (it's annoying enough when people post > gzipped attachments) I know that there are people who do everything in Emacs -- email, software development, diary, contact list, off we go. I understand that Emacs contains a Lisp VM, so in the end you could even write your private version of Doom on it, given a decent enough underlying platform (I guess 10GHz PVI would do ;-). But why do you expect to be able to do everything in your mail reader? Especially, why do you think that a mail reader is a good tool to manage software development process? I know that you probably attached yourself to thinking of the mail reader as a software development management tool, but that's just one of nonsensical things that barebones CVS installation forces you to do and I doubt there's anything more to it... It makes about as much sense as complaining that you have to switch away from your mail reader to play Quake. What does game playing and software development management has to do with mail reading??? Cheers, Kuba Ober
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Fri, Mar 14, 2003 at 02:57:07PM +0100, Andre Poenitz wrote: > application/x-gunzip; gunzip -c %s; copiousoutput > in my /etc/mailcap and everything "magically" works. Well I'd need some way to do that w/o changing /etc/, and I'd really like to have the patch inline as well ... guess it's possible somehow john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Fri, Mar 14, 2003 at 02:03:26PM +, John Levon wrote: > > gzipped should be no problem > > It's actually a lot of hassle for me Why? I have something like application/x-gunzip; gunzip -c %s; copiousoutput application/x-gzip; gunzip -c %s; copiousoutput application/gzip; gunzip -c %s; copiousoutput application/x-tar-gz; gunzip -c %s | tar -tf -; copiousoutput application/x-tgz; gunzip -c %s | tar -tf -; copiousoutput application/x-bunzip2; bunzip2 -c %s; copiousoutput application/x-bzip2; bunzip2 -c %s; copiousoutput in my /etc/mailcap and everything "magically" works. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Fri, Mar 14, 2003 at 02:43:44PM +0100, Andre Poenitz wrote: > gzipped should be no problem It's actually a lot of hassle for me john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Fri, Mar 14, 2003 at 01:46:56PM +, John Levon wrote: > Actually, context switching out of my mail reader just to review a > patch would be a major PITA (it's annoying enough when people post > gzipped attachments) gzipped should be no problem, the PITA is undeclared contents... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Fri, Mar 14, 2003 at 08:36:10AM -0500, Kuba Ober wrote: > Just imagine how much easier the life for Lars and all other potential > reviewers would be, if instead of scouring the list for stuff to review, and > everybody else complaining "my patch has been ignored, so here it is again Actually, context switching out of my mail reader just to review a patch would be a major PITA (it's annoying enough when people post gzipped attachments) john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Fri, Mar 14, 2003 at 08:20:44AM -0500, Kuba Ober wrote: > No matter how small or "insignificant" a change is, there should be a way to > review it without having to post a patch to the mailing list. Sure - get the machinery to post patches. It's as easy in CVS as anything else. > And the fact that a change either passed review or was rejected should be documented > so > that is accessible. We simply don't need formal machinery - the mailing list is good enough. john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On piątek 14 marzec 2003 06:27 am, John Levon wrote: > On Fri, Mar 14, 2003 at 11:27:29AM +, Jos? Matos wrote: > > On Friday 14 March 2003 11:16, John Levon wrote: > > > Plus the duplication of the changelong in the commit - most commit > > > messages are good enough just being the changelog > > > > I remember to have seen some experiments from Lars where the Changelog > > diff was expanded in cvslog. If that was done then the commit message > > could only be the title for the whole changes. > > Sometimes though it's useful to add notes (please test etc.). So we > could make it always add the ChangeLog diffs but also pick something up > from the commitlog... Changelog, commitlog, oh boy ;-) Well, aegis keeps all data about a change, including the history of various states the change went through, in a place that you access via simple ael cd which stands for "AEgisList ChangeDetails". You can instantly see if the change passed the review or failed, if it failed then what was the reason given by the reviewer, etc. I guess life gets a tad more organized when you can do things like the following, all within the framework: # these are the actual things from my project $ aegis -list -unformatted c | grep awaiting_development 31 awaiting_development Add targeted limit of stability 75 awaiting_development Add waveform display 76 awaiting_development Sorting of the tables 77 awaiting_development Fix height conversion roundoff errors 78 awaiting_development Collective results printing 79 awaiting_development Nicer CoP markers $ aegis -list -unformatted c | grep awaiting_review 93 awaiting_review Streamline the I/O framework Obviously, (for you keystroke minimization freaks) one is free to add shortcuts (aliases) to these, and I guess we can have our own aegis alias file so that if somebody invents a nice shortcut, everybody could use it. Just imagine how much easier the life for Lars and all other potential reviewers would be, if instead of scouring the list for stuff to review, and everybody else complaining "my patch has been ignored, so here it is again [and then its outdated, and they have to rediff] they would just list changes awaiting review and access the diffs via *two* commands. Suppose somebody is to review my change 93: $ ae_c 93 $ aedless That's all -- the diffs (with *full* context) are just displayed via less. And note -- at any stage before change's integration, you can change the description of a change (the one liner as well as the extended one). So, you could put something like "Move some more stuff over to boost graph (Lars, plz review)" and then, after Lars reviews it, he just deletes the stuff in parentheses. So there's some room for creativity -- Aegis doesn't preclude having fun! Cheers, Kuba Ober
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On piątek 14 marzec 2003 06:16 am, John Levon wrote: > On Fri, Mar 14, 2003 at 09:01:20AM +0100, Andre Poenitz wrote: > > vi insets/Changelog > > [insert changelog] > > cvs commit > > [write 'Fix for missing space as reported by Angus] > > > > :wq > > > > The "cvs overhead" is 'cvs up' + 'cvs commit', i.e. 18 keystrokes. > > What would be the corresponding aegis version? > > Plus the duplication of the changelong in the commit - most commit > messages are good enough just being the changelog Luckily, Aegis manages *both* the Changelog and the TODO for you, and it comes free. No more Changelog and TODO files to edit ;-) Cheers, Kuba Ober
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
> Hm. Ok. Let's count keystrokes for a minimalistic real life example. > Let's suppose Angus told me there is a space missing in inset/insetenv.C. > > I do > > cvs up > vi insets/insetenv.C > [insert the space] > > :wq > > vi insets/Changelog > [insert changelog] > cvs commit > [write 'Fix for missing space as reported by Angus] > > :wq > > The "cvs overhead" is 'cvs up' + 'cvs commit', i.e. 18 keystrokes. > What would be the corresponding aegis version? [invoke whatever script you have to sync with the master -- it depends on the setup, obviously it's a single command] aenc [write 'Fix for the missing space as reported by Angus] ae_c xxx [choose the change you've just created] aecp insets/insetenv.C vi insets/insetenv.C [insert the space] aeb && aed && aede aerpass aeib && aeb && aed && aeipass [invoke whatever other script to sync with the master again] Note that aeb && aed && aede are trivial to put into a single alias (the ae stuff are aliases for aegis -x anyway), just as aeib && aeb && aed && aeipass are If you are really that conscious about the number of keystrokes that you do, it's trivial enough to have say an "aetriviale" alias which wraps up the change all the way to the repository (as in building, passing review, integrating, syncing integration to the rep). > > One of significant drawbacks of CVS is that it effectively prevents you > > from sharing your work in progress > > Which, in an ideal world, is not much of a problem, as changes should be > small and self-contained. LyX, of course, is not the ideal world... No matter how small or "insignificant" a change is, there should be a way to review it without having to post a patch to the mailing list. And the fact that a change either passed review or was rejected should be documented so that is accessible. Although mailing lists are commonplace to do that, it's not the correct approach. A database which keeps all that information is simply provided with Aegis, it comes for free, there is a read-only web interface for Aegis that comes by default with Aegis itself. > Ok, maybe aegis is really better in large projects, but I don't think, LyX > reaches that critical mass. I use it for a 13k line project of mine (among others). I also use it for a webpage structure that has about 500kb of text. I also use it for DNS, which has about 30k in config and domain files all together. > This was btw my impression when we used aegis > in our two-or-three-person-project I mentioned earlier. I don't think that keeping a well accessible record of what was done, when and by whom is something that small projects can simply ignore. It also has the added benefit that one teaches himself some self-discipline. I guess it would even look good on the resume. Cheers, Kuba Ober
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Fri, Mar 14, 2003 at 11:27:29AM +, Jos? Matos wrote: > On Friday 14 March 2003 11:16, John Levon wrote: > > > > Plus the duplication of the changelong in the commit - most commit > > messages are good enough just being the changelog > > I remember to have seen some experiments from Lars where the Changelog diff > was expanded in cvslog. If that was done then the commit message could only > be the title for the whole changes. Sometimes though it's useful to add notes (please test etc.). So we could make it always add the ChangeLog diffs but also pick something up from the commitlog... john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Friday 14 March 2003 11:16, John Levon wrote: > > Plus the duplication of the changelong in the commit - most commit > messages are good enough just being the changelog I remember to have seen some experiments from Lars where the Changelog diff was expanded in cvslog. If that was done then the commit message could only be the title for the whole changes. The cvs log is just an example of browsing the changes, any other method will not differ significantly from it. > john -- José Abílio
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Fri, Mar 14, 2003 at 09:01:20AM +0100, Andre Poenitz wrote: > vi insets/Changelog > [insert changelog] > cvs commit > [write 'Fix for missing space as reported by Angus] > :wq > > The "cvs overhead" is 'cvs up' + 'cvs commit', i.e. 18 keystrokes. > What would be the corresponding aegis version? Plus the duplication of the changelong in the commit - most commit messages are good enough just being the changelog john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Thu, Mar 13, 2003 at 02:40:31PM -0500, Kuba Ober wrote: > 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. Hm. Ok. Let's count keystrokes for a minimalistic real life example. Let's suppose Angus told me there is a space missing in inset/insetenv.C. I do cvs up vi insets/insetenv.C [insert the space] :wq vi insets/Changelog [insert changelog] cvs commit [write 'Fix for missing space as reported by Angus] :wq The "cvs overhead" is 'cvs up' + 'cvs commit', i.e. 18 keystrokes. What would be the corresponding aegis version? > One of significant drawbacks of CVS is that it effectively prevents you from > sharing your work in progress Which, in an ideal world, is not much of a problem, as changes should be small and self-contained. LyX, of course, is not the ideal world... Ok, maybe aegis is really better in large projects, but I don't think, LyX reaches that critical mass. This was btw my impression when we used aegis in our two-or-three-person-project I mentioned earlier. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
> > 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 worki
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Thu, Mar 13, 2003 at 04:36:09PM -0500, Kuba Ober wrote: > > 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). where does this number come from then ? > 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). wow, too much ... /me runs > 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. The thing should simply notice what's changed and handle it like that. > 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 This would be nice to have but realistically it won't and can't happen john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
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
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Thu, Mar 13, 2003 at 04:07:56PM -0500, Kuba Ober wrote: > > Quality is not and never was the most important thing with lyx. There > > are some (rare) projects where it is ... not here... > > I'm not claiming it's *the* most imporant thing. Nevertheless, it is somewhat > important, right? Hopefully :) > 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. It really is that simple. I don't know if Meta-CVS can handle this, but 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. Aegis seems to do this, but its way too high an overhead in terms of type this, then that, then the other, it seems. regards john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On czwartek 13 marzec 2003 02:52 pm, John Levon wrote: > On Thu, Mar 13, 2003 at 02:45:29PM -0500, Kuba Ober wrote: > > > Some of us don't want configuration management. > > > > The quality of software has been shown to be worse without one ;-) > > Quality is not and never was the most important thing with lyx. There > are some (rare) projects where it is ... not here... I'm not claiming it's *the* most imporant thing. Nevertheless, it is somewhat important, right? > > > That's making unwarranted assumptions. Actually I'd like to avoid as > > > much administration as possible. That means not having to wait for > > > formal reviews, not having to open PRs before a fix can be accepted etc > > > > PR's? Gosh, it can be a one-liner! You have to put a changelog entry > > anyway, > > I was referring to e.g. Mozilla's model I don't know Mozilla's model. In Aegis, you can put as much or as little info into the change description as you feel like. You can even have anonymous changes. They are then only identified by number. 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 changes -- say if you work on newest dialogs, it's worthwhile fixing say the few loosely related bugs that the new dialogs seem to uncover in a separate change. First of all that change will be small and it will be up for integration much quicker, and second of all this methodology has been asked over and over by Lars (as in: please send small, separate patches). That's almost like him asking to do things in separate changes, and have the integrated one at a time. I'm with Lars here: I have found that doing my own development like this, things are easier to keep under control, and I don't mix bugfixes with the feature enhacements that I happen to be working on at the time. Things are neatly separated, and the customers can get the fixes very quickly. The nice thing is, that if you feel like doing somebody else's wishes or bugs, you just use $ ael c to list all changes in current branch -- some of these changes will be in awaiting development state, so they are up for grabs. Or, if you feel like implementing your next killer feature, just create a change for it. Even better - if you have just an idea for a killer feature but no will/time to implement it, you can create a change ASAP. The development on it doesn't need to actually start right away. It can sit there, you can add more thoughts to the description, and finally you or somebody else could pick it up at a later time. Ah well, IIRC Aegis has a CVS repository migration tool, which automatically generates changes and branches for previous development work. It even has some intelligence to it (tries to decide which files went into each change - so sometimes it can merge commits if it decides they are somehow related). I never used it, but it's supposedly there. Cheers, Kuba Ober
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Thu, Mar 13, 2003 at 02:45:29PM -0500, Kuba Ober wrote: > > Some of us don't want configuration management. > > The quality of software has been shown to be worse without one ;-) Quality is not and never was the most important thing with lyx. There are some (rare) projects where it is ... not here... > > That's making unwarranted assumptions. Actually I'd like to avoid as > > much administration as possible. That means not having to wait for > > formal reviews, not having to open PRs before a fix can be accepted etc > > PR's? Gosh, it can be a one-liner! You have to put a changelog entry anyway, I was referring to e.g. Mozilla's model john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
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 ? > 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 ? > 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). At the very least I need a full source tree available directly that I can play around in. > 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 > 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 ? 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. > 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. john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On czwartek 13 marzec 2003 02:31 pm, John Levon wrote: > On Thu, Mar 13, 2003 at 02:19:14PM -0500, Kuba Ober wrote: > > I guess the whole problem is that *any* replacement for CVS is doomed to > > be bound with same basic issues. I don't think that there's a need for > > another version control system. There's a need for a software > > configuration management tool > > Some of us don't want configuration management. The quality of software has been shown to be worse without one ;-) > > CVS is good what it's good for > > No it's not. Okay, I'm not using it much, so I don't argue anymore. > > it's just that if you're managing real-life projects, you do much more > > than just version control. > > That's making unwarranted assumptions. Actually I'd like to avoid as > much administration as possible. That means not having to wait for > formal reviews, not having to open PRs before a fix can be accepted etc PR's? Gosh, it can be a one-liner! You have to put a changelog entry anyway, right And with Aegis, the Changelog *and* TODO lists can be both generated automatically. > > If the consensus is that nobody needs anything more than version control, > > then CVS is fine. > > It emphatically is not fine. > > > does move from a non-VCS environment to one with any VCS. Aegis is about > > 10 years "old" right now, it's used to manage large development projects > > (not only in software). > > We're not a large project and we don't need or want admin overhead. I do > not believe that a lot of boondage and discipline will decrease the bug > rate for us ... it's supposed to be fun, at least in part. Life is very fun with Aegis. Almos everybody can put their wishes in as changes awaiting development, and you have a simple, development-bound interface for it. It's integral with version control. You don't need to use Bugzila, then. The process has very loose rules, and you can always be a self-reviewer and self-administrator. These are all per-project configurable. And the self-discipline that it teaches you is really beneficient. I guess I became a slightly better and more organized developer because of that. And you get all the stats for free (as in how long it took whom to do what, etc)! Cheers, Kuba Ober
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
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
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Thu, Mar 13, 2003 at 07:31:10PM +, John Levon wrote: > We're not a large project and we don't need or want admin overhead. I do > not believe that a lot of boondage and discipline will decrease the bug > rate for us ... it's supposed to be fun, at least in part. I take it back, "boondage" sounds like it might be fun john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Thu, Mar 13, 2003 at 02:19:14PM -0500, Kuba Ober wrote: > I guess the whole problem is that *any* replacement for CVS is doomed to be > bound with same basic issues. I don't think that there's a need for another > version control system. There's a need for a software configuration > management tool Some of us don't want configuration management. > CVS is good what it's good for No it's not. > it's just that if you're managing real-life projects, you do much more > than just version control. That's making unwarranted assumptions. Actually I'd like to avoid as much administration as possible. That means not having to wait for formal reviews, not having to open PRs before a fix can be accepted etc > If the consensus is that nobody needs anything more than version control, then > CVS is fine. It emphatically is not fine. > does move from a non-VCS environment to one with any VCS. Aegis is about 10 > years "old" right now, it's used to manage large development projects (not > only in software). We're not a large project and we don't need or want admin overhead. I do not believe that a lot of boondage and discipline will decrease the bug rate for us ... it's supposed to be fun, at least in part. john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On czwartek 13 marzec 2003 05:05 am, Dekel Tsur wrote: > On Wed, Mar 12, 2003 at 10:50:48PM +0100, Lars Gullik Bj?nnes wrote: > > | Another alternative is Subversion. > > > > I would at least wait for version 1.0. > > Yes, but if you feel that Subversion will become the CVS replacement, then > we should wait until it is finished, and not move to Aegis. I guess the whole problem is that *any* replacement for CVS is doomed to be bound with same basic issues. I don't think that there's a need for another version control system. There's a need for a software configuration management tool -- an entirely different beast. CVS is good what it's good for, it's just that if you're managing real-life projects, you do much more than just version control. If the consensus is that nobody needs anything more than version control, then CVS is fine. No need to switch. If the consensus is that an SCM tool is what's really needed, then Aegis is a very mature tool that has excellent track record, it's GPL, and it rocks. It needs an attitude switch, but so does move from a non-VCS environment to one with any VCS. Aegis is about 10 years "old" right now, it's used to manage large development projects (not only in software). I'm not pushing for anything -- as I said, I'm using it myself and I'd be happy to aid in the deployment. It makes me a happier developer and that's all that counts (yes, I'm selfish here). If a VCS is all that LyX developers think they need, I guess there's no arguing with that. Cheers, Kuba Ober
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
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 ? > $ 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. > $ ae_c 110 > # okay, we choose to work on change number 110 what on earth ... ? > $ 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 ? > $ 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. > $ aedist -send | mail -s integrate [EMAIL PROTECTED] > # upload to the server which should handle the rest automagically Anyway I'm not sure a discussion on Aegis is relevant or fruitful :) john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On środa 12 marzec 2003 02:19 pm, John Levon wrote: > On Wed, Mar 12, 2003 at 02:13:16PM -0500, Kuba Ober wrote: > > Probably because Aegis, although a very cleanly and understanably coded > > project, is essentially one man's work for most part. If something > > happens to > > It's more likely that it can't handle what he needs. I doubt he would use a tool that has only one person behind it, for all practical purposes. It has some very real implications if say Peter would decide to stop working on it. > at least your > description of how things work put me right off it (that is, I couldn't > follow it within 10 seconds or so of reading it). What're all these > obscure edit and send commands etc. ? > > We just don't need administration overheads. All I want is properly > distributed repos, it's that simple :) 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: $ 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 $ tkaenc # a gui pops up and lets you type a change information $ ae_c 110 # okay, we choose to work on change number 110 $ aedb # begin development $ aecd; aecp README # add the README file into the change $ 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 $ aedist -send | mail -s integrate [EMAIL PROTECTED] # upload to the server which should handle the rest automagically Cheers, Kuba Ober
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Wed, Mar 12, 2003 at 10:50:48PM +0100, Lars Gullik Bj?nnes wrote: > | > | Another alternative is Subversion. > > I would at least wait for version 1.0. Yes, but if you feel that Subversion will become the CVS replacement, then we should wait until it is finished, and not move to Aegis.
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Wed, Mar 12, 2003 at 07:23:10PM +0100, Lars Gullik Bj?nnes wrote: | > Kuba Ober <[EMAIL PROTECTED]> writes: | > | > I'll have a look at aegis. | > | > At first glance it seems to be similar to BitKeeper? What are the | > differences? (And why doesn't Linus want to use aegis?) | > | > I'll go through the documentation. | | Another alternative is Subversion. I would at least wait for version 1.0. -- Lgb
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
Dekel Tsur <[EMAIL PROTECTED]> writes: | On Wed, Mar 12, 2003 at 07:23:10PM +0100, Lars Gullik Bj?nnes wrote: | > Kuba Ober <[EMAIL PROTECTED]> writes: | > | > I'll have a look at aegis. | > | > At first glance it seems to be similar to BitKeeper? What are the | > differences? (And why doesn't Linus want to use aegis?) | > | > I'll go through the documentation. | | Another alternative is Subversion. Which is even more unfinished. -- Lgb
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Wed, Mar 12, 2003 at 07:23:10PM +0100, Lars Gullik Bj?nnes wrote: > Kuba Ober <[EMAIL PROTECTED]> writes: > > I'll have a look at aegis. > > At first glance it seems to be similar to BitKeeper? What are the > differences? (And why doesn't Linus want to use aegis?) > > I'll go through the documentation. Another alternative is Subversion.
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On Wed, Mar 12, 2003 at 02:13:16PM -0500, Kuba Ober wrote: > Probably because Aegis, although a very cleanly and understanably coded > project, is essentially one man's work for most part. If something happens to It's more likely that it can't handle what he needs. at least your description of how things work put me right off it (that is, I couldn't follow it within 10 seconds or so of reading it). What're all these obscure edit and send commands etc. ? We just don't need administration overheads. All I want is properly distributed repos, it's that simple :) john
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
On środa 12 marzec 2003 01:23 pm, Lars Gullik Bjønnes wrote: > Kuba Ober <[EMAIL PROTECTED]> writes: > > I'll have a look at aegis. > > At first glance it seems to be similar to BitKeeper? What are the > differences? (And why doesn't Linus want to use aegis?) > > I'll go through the documentation. Probably because Aegis, although a very cleanly and understanably coded project, is essentially one man's work for most part. If something happens to Peter Miller ( forbid), Aegis becomes (at least for a while) a project without maintainer, and without architect's support. I guess Linus had to use something that has strong commercial backing, and I understand that decision. And, because Bitkeeper has a company behind it (rather than a single person in case of Aegis), the requests for improvements and fixes can be integrated quicker. Although Aegis is open source and GPL, it's still currently being developed mainly by one person. One of the reasons why it may be unpopular is that Peter hates recursive make :), and rightly so. He wrote a very educational article why recursive make is harmful. I hate recursive make too, so I don't use it :). I guess that it's hard for people who are used to autotools and recursive makefiles the autotools generate to understand that there are better things to do with life than hunting brokenness which is handled all right by simpler and more powerful tools (as in automake+gmake replaced by cook). My guesstimate is that projects of LyX's size and developer diversity, if moved from CVS and automake (let's leave autoconf in for the time being, it's needed for some stuff) over to Aegis and Cook, can save about 5% of recurring developer time, after a short "adjustment" period of a 2-3 months, when productivity might suffer while people get used to better tools and forget limitations of the previous tools ;-). Personally, I'm lucky not to need autoconf for my projects (I build on latest RedHat and on Windows only), so I'm just using cook and Aegis, and it works fine for both linux and windows builds. Windows builds need some wine trickery, but once you do it and put into scripts, with Aegis multiplatform support it becomes a breeze. Aegis will even tell you that say an integration build succeeded on Linux/GCC platform but failed on Windows platform, and then you're back to workarounds for your not-so-favourite Windows compiler :). Oh, I use BCC55, so I'm not complaining too much -- it was much worse with VC6. Cheers, Kuba Ober
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
Kuba Ober <[EMAIL PROTECTED]> writes: I'll have a look at aegis. At first glance it seems to be similar to BitKeeper? What are the differences? (And why doesn't Linus want to use aegis?) I'll go through the documentation. -- Lgb
Re: Aegis (was: Re: [PATCH] use ParagraphList iterator for reading the doc)
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.
