Re: [Arx-users] Real-world ArX usage

[Amine Chadly]

> Until I implement hash names for revisions, every developer has to
> have their own branch.  Otherwise, you could easily wind up with two
> revisions with the same name.

I see, it does makes sense, although the fork command might scare a few
at first glance ;-).

> <snip>
> > > 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.
> 
> If you all have access to a shared filesystem, you can drop requests
> in a special directory.

I guess this can be done with sftp, which would be necessary for
accessing the repository.
Did you know the gnome sftp didn't work if you didn't have the
auto-login feature ?
It makes you get a weired error message in ArX that I don't remember...
just try to access a legit archive from a machine for which you don't
have automatic access.

> > > In a perfect world, it would monitor each
> > > developer's mirrored archive, and automatically initiate the merge.
> 
> Are you sure you want to do that?

I am sure I don't want that. Each developer has to decide when his
changes are mature enough for him to commit to the central archive.

> > > I'm not sure whether we would prefer to pull these patches
> > > individually, or as a combined group.
> 
> Unfortunately, you pretty much have to pull them as a group.  Making a
> "merge" command that applies patches one-at-a-time with appropriate
> summaries is on the todo list.

I actually tend to think that it wouldn't be necessarily a great thing.
After all the history of the changes are kept in the developer archive
if they are really needed.
If the developers have enough discipline to commit often enough to the
main archive, this shouldn't be a problem...
It's just a way to avoid having a heavy history to carry for large
projects.

> 
> > 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.
> 
> You would actually email the patch queue manager (pqm) to have it
> create the master archive.  The pqm is designed so that almost any
> operation you need can be done through email.

<snip>

> Alternately, you could branch off of the (mostly empty) master
> archive, add all of files, and ask the pqm to merge.

The documentation about this is too hidden Walter :-), you should to
make it available on the website :-), and I would strongly advice that
the examples integrate the use of the pqm. After all, every project that
has more than one guy working on it, would need this to take full
advantage of ArX don't you think ?

I can see a few --in-place arguments in the arch-pqm... so my wild guess
is that it needs to be updated to follow the latest changes ;-).
I am willing to spend some time to make the changes so we get an fully
functional arch-pqm.
Actually shouldn't we call it arx-pqm and remove all that arch related
code as we are not compatible with them anymore ?

I am not really satisfied with those little scrips one has to make to
use the patch queue manager. Don't you think the commands should be
available as build-in arx commands ?

In any case, let's try to build the scenario that should be available
after the development of the tool ;-)

First possibility : You want to receive the patch requests by mail.
You then have two solutions, either you create an account for the patch
queue manager (easiest way), or send the mails to the release engineer.

In the case you created an account for the patch queue manager, you just
have to run the patch queue manager for all incoming mail with the
following .procmail file:

:0:
| arx-pqm --read

--> Man don't put the email address in public html pages, or the patch
queue manager is going to try to merge with all the spam he is going to
receive ! :-).

You can send the emails to the release engineer, with some specific
subject format. I have no procmail knowledge and the following
suggestion is _untested_, you have been warned:

:0:
* ^Subject:[PQM]:.*
| arx-pqm --read

In the above, the subject starting with [PQM]: ought to trigger the
patch queue manager.
We could tweak the arx-pqm to look for that in the subject, and take it
out of it, so it doesn't show up in the commit message.
It would be more elegant to do that directly in procmail, if you know
how to do that, please let me know.


Second possibility: You are going to get the patches from somewhere in
the filesystem. This implies that you give write access somewhere in the
release machine to all main contributors. (which is not bad, just a
potential hassle).

The location where the patches will be stored have to be indicated in
the .arx-pqm.conf configuration file.

In all cases, you have to make sure the 'arx-pqm --run' command is ran
from time to time to process the requests sitting in the queue
directory. (A typical cron job candidate).

Ok, now we can assume the patch queue manager reads mail for commands
whenever one arrives for him.

Now to the creation of the master archive.

So my guess is that you need the arx commands inside the body of the
email. So you would end with :

make-archive repository--application_main file://path2repository

Do we need to make an init here, or can we assume that we already have
that mostly empty archive you mentioned in your email ?
In any cases, let's assume it's ok. (You'll correct me in your answer).

Each developer has to create his copy:
arx archives -a path2archive
Makes the main archives reachable, then

> Create a private branch
> 
>   arx get repository--application_main/application app
>   cd app
>   arx fork my-repo/application

Once this is done, all the commits will be send to our local fork
right ?

>   (hack, hack, hack)

ok, ok, ok ;-)

>   arx commit -s "Useful hacks"

I assume the changes are sent to the local developer archive.

>   (send an email to the pqm asking for a merge)

Can't we create a command that does that instead of those ugly shell
scripts ? Something like :
arx queue-patch -s "Fixed so many bugs" [--dir DIR]

That would generate a patch between the tree containing DIR (or the
current directory) and the revision we forked from. Then, mail
everything to the patch queue manager. 

I can imagine you thinking, where does arx guess what is the mail
address, or the directory where the patch should be sent to ?
Can't we have that as a  meta-info of the repositories ?
The creation of archives could become :
arx make-archive --pqm address@hidden
repository--application_main file://path2repository

or arx make-archive --pqm /var/arx-pqm/application/
repository--application_main file://path2repository

I am just throwing suggestions around, what do you think about it ?

In any case, for now, I would be sending an email to the patch queue
manager address, with the following script:

#!/bin/sh
echo start-merge "something that indicates the local branch and revision
" "repository--application_main/application" | mail -s "$1" "$2"

The star-merge will probably disappear as we are not bound to the arch
protocol anymore.

If I understand correctly, the script sends a command to the arch-pqm,
wich queues it with the arch-pqm --read.
when you execute arch-pqm --run, it performs the queued operations: goes
to each developper archive, and pulls the differences away from those
branches.
If that's true, I don't really like this ! :-).
It implies that the developer archives are public, and constantly
available, doesn't it ?
What if the guy codes on a laptop, and run around many places ?
The forces him to have two local repositories (one on his laptop, and
one in a public stable location) and work it out !
Wouldn't it be better to send the diffs in the mail itself and up to the
patch queue manager to sort it all out ?

Well that was a lengthy email (sorry about that :-).
I'll be patiently waiting for your light, and corrections, I know you
are busy theses days ;-).
I'll be working on the gnome-vfs replacement for the sftp handling.
I didn't manage to get the gnome-vfs sftp module work on mac OS X !
I keep on getting a libsftp.so not found error, so I am really motivated
to get that dependency out.

Read you soon,
 -amine