Re: [Arx-users] Real-world ArX usage (was: ArX and simplicity)

[Amine Chadly]

On Fri, 2005-04-29 at 08:41 -0400, Kevin Smith wrote:

> Our team has 3 developers--2 in a California office, and one working
> remotely from Florida. This is a Java project which is GPL, but it is
> run more like a closed project, so it is important that pre-release
> versions not get out. One developer exclusively uses GNU/Linux, and
> another exclusively uses MS Windows. We also have a dedicated cygwin
> build machine. Two of us actively review *all* code that gets checked in.
> 
> Here goes...I'm making this up as I go along!
> 
> My vision is that our current CVS server would become our central ArX
> server. It would host a "master" archive, which would represent the
> official tree from which we would do releases. This master archive would
> primarily be controlled by the guy who does the builds, but the other
> developers would have the passwords to be able to take over when he is
> not available. The master would only be available via ssh.
> 
> Each developer would have their own local working archive, which would
> be a branch off of the master. We would frequently (~hourly?) do a diff
> between the master and our working archive. For each new patch, we would
> review the incoming code, and then pull it into our local branch.

Question: What is the best scenario here : that every developer archive
be a mirror of the central ArX archive, or that each forks his own
branch ?

> 
> As we complete each small coding task, we would run any relevant tests,
> review our patch, and commit it to our local archive. As we complete
> each related small group of tasks, we would run our full test suite and
> then mirror our local archive to a remote copy on the server, via ssh.

What about having a repository on each developer machine that will
receive only versions that ought to be published in the main ArX
repository ? Just to avoid having to give any access to it to any
developer...

> Then, I think we would use the patch queue manager to merge each
> developer's changes into a staging mirror of the master archive. I
> haven't looked at the PQM yet, but we would want a way to trigger it
> without using email. In a perfect world, it would monitor each
> developer's mirrored archive, and automatically initiate the merge. I'm
> not sure whether we would prefer to pull these patches individually, or
> as a combined group.

Ok, let's see if I find how to get this done:
First I would create the repository and archive on the the main ArX
server.

Second each developer would create a local mirror of that archive on his
machine. Shall we keep ArX looking by default at the remote archive (the
main ArX server), so each integrated change ends up in our local work
directory or shall we make the local archive as default, and get the
global change by mail from the central repository ?

Three each developer sets up an publicly accessible archive that will
keep the changes that he wants to commit back to the ArX main server.
Each commit to these archives has to send a mail to the main Arx server
that will integrate the change.

When the release engineer wants to get one done, he tags it on the main
ArX server, checks it out, test it, polishes it, and possibly release it
if everything is fine.

Please let me know what you think about this way of setting things up.

Now to the commands :
let's say we have the 3 developers machine named dev1, dev2 and dev3.
The main ArX server is repository.
Everything is in the example.net domain.
Note: sftp won't work if you don't have ssh auto-login.

Creation of the main repository:
 $ arx make-archive repository--application_main
sftp://repository/example.net/path2project/ 

If there is existing source code, you go to the root directory, and then
 $ arx init repository--application_main/application
Creates the branch application in the main ArX server.

Each developer to create his copy types:
 $ arx make-archive --mirror repository--application_main/application
file://localpath2project

Ok now, I am stalled and have to wait for your answers :-).

Let me know if I am just being stupid and annoying here :-).
 -amine