Sorry this is so long.
That’s exactly what I needed. It’s more that aegis docs are a little hard
to deal with sometimes and it is a much more complex system than CVS with
a fairly different mindset, which requires some serious work to wrap one’s head
around fully.
NOD Don’t let it get you down though, UNIX seems complicated to many at first
and later seems quite simple 
(or not)
I guess the one thing that still doesn’t seem easy
is to provide anonymous read-only access to the live repository.
MORE TO FOLLOW
Is the right thing there just to script aedist into a commit hook?
That is certainly one way to do it.
It is probably the way I would do it if I were you.
All of the .ae files created could be placed on the website or posted to the
devel list or both.
On the client side, I guess a small perl script that does a wget of the .ae
file and an aerecieve would mostly mimic “cvs update” against a remote
repository.
Sure, but it may not be necessary.
I think you could make many people happy by doing an aecp -INDependent of the
current development branch and allowing an rsync of it. rsync should give
everyone all of the easy access they had with anon CVS, its compressed
transfer, can be anonymous, can use ssh, etc. etc.
For the developers you can let them acquire the .ae files to update thier own
repository.
Or could a script actually ssh to the aegis server and do an aedist|aerecieve
(on the local host) on demand?
While I think this could be done, I think you would need to set up a user for the
project that was capable of doing the aedist -send and the privledges for doing
that may be too high for a “give away” script.
If the rsync solution above doesn’t work, perhaps there is a better way than
shell access(ssh or otherwise).
I guess here is what I envision.
C2
//========\\
// \\
BL ==\=========A=====//=======A…\==B====================B…//======F
\ //
BR1 \=\====\==========//=+C==\==========//+D=//===E=====//
\ \ // | \ // | //
\ \==C1==// | \==C3==// | //
\ | | //
\====JC1========+===================+//
This eye exam is just a hypothetical example.
The BL is the baseline and represents the stable RT project line. BR1 is the
branch created for development of the next release of RT.
So you ,Jesse, create JC1 and start working in the newest feature of RT. While
you are working, a contributor gets a copy of the aedist -send -baseline .ae
from the website and creates a feature. This person does an aedist -send for
their change and sends it to you. You do an aedist -receive against BR1 and
this contributed change becomes C1. You approve of C1 and integrate it into
BR1.
Now the aecp -INDependent takes a copy of BR1 and puts it where people can
rsync it. Thus everyone can have a change as soon as it is INTEGRATED. We are
at point C above. This is important because aegis can help insure that code
in a change meets requirements before being integrated. The other thing to
note here is that BR1 does not contain files of its own, it only holds the
files that are integrated from changes(C1, C3, and JC1 in this case) so there
are no partially edited files, or partially completed changes in BR1. If you do
an aegis -DIFference on JC1 you can perform a merge with conflicting files from
BR1, thus JC1 stays up to date (thats the vertical bar showing a merge if
necc.).
Just then you realize a security fix needed for the stable RT. So C2 is created
on the BL. You create the fix and test and integrate it and release the fix.
Not too different from CVS really. People get the updated stable line from an
rsync -or- from the .tar -or- an aedist -send -baseline (if they are starting
their own repository). Those maintaining their own repository can update by
using the aedist -send .ae for the change. The BL is now at point B above.
Another change is posted to the list and it is aedist -receive(d) and
integrated into BR1 as before, and becomes C3 above. An aed will update JC1 as
before, and the nightly aecp -INDependent will update the directory that the
rsync daemon is serving to all of those on the “bleeding edge”. Point D
above.
Then JC1 is complete and RT now has spontaneous money generation. It is
integrated into BR1 and the “bleeding edge” people catch it from the net via
rsync and try it out. Those maintaining their own private repository will want
the aedist -send of JC1. Point E above.
If no bugs are found in the BR1 code by those trying it out, eventually BR1
gets integrated back into the BL and becomes the current stable RT. Point F
above. It all starts over again.
So there it is, there are two rsync directories, stable and devel. And there is
a list of .ae files that can go against the stable branch (hotfixes) and a list
of .ae files for the development branch. All of the .ae files are for those
maintaining their own repository.
I would also suspect you would have .tar distros for A, B, and F above.
Your laptop scenario can be handled in a couple of ways, one is to keep an
autonomous repository on it, but this might be too labor intensive with all of
the aedist actions needed to keep it up to date. Otherwise if you have network
mounted drives you can do an aecp --readonly to bring all of the files onto the
workspace on the laptop and later to an aecpu to remove the ones that haven’t
changed. Leaving only the modified files in the change. If this doesn’t make
sense, let me know. There are a few threads in the mailing list archives about
different stategies here. More than I can remember right now.
Is there a nice aegis webui somewhere?
There is an aegis .cgi in the distro. (I haven’t used it so I don’t know if its
nice.)
There is a Tcl/Tk UI in the distro.
There is a GTK gui for aegis called “ages” at:
http://ages.sourceforge.net (re-directs to)
http://psionic.de
Thanks,
Jesse
Your Very Welcome,
Joshua
