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

[Walter Landry]

Amine Chadly <address@hidden> wrote:
> 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.

I will put a note in the manual.  Thanks.

<snip>
> > > 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 :-),

It is not obvious, but you can browse it at

  http://superbeast.ucsd.edu/~landry/ArX/ArX-2.2.2/tools/arch-pqm/arch-pqm.html

> 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 think a pqm is mostly for larger projects where having someone run
the merges manually is too much work.  For small projects, a simple
"please merge me" email will work.

> 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 ;-).

Yeah, I think it bit-rotted a little.  I don't have automated tests to
make sure that the stuff in "tools/" always works.

> I am willing to spend some time to make the changes so we get an fully
> functional arch-pqm.

Great!

> Actually shouldn't we call it arx-pqm and remove all that arch related
> code as we are not compatible with them anymore ?

I originally got it from Colin Walters, but I think Robert Collins is
doing most of the work now.  We may be able to use Robert's work, so
it would be good to talk to him first.

> 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 ?

We should definitely have a "send" command.  That would allow you to
directly send patches instead of merges to the pqm.  That solves the
problem of intermittent access.  It would also be useful for sending
patches to mailing lists.

We might also want to put in an option to "send" that only sends a
merge request.  Alternately, we could have the "queue-patch" command
you suggest below.

<snip>
> --> 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 ! :-).

The first thing the pqm does is check for a gpg signature.  So I don't
think the load will be all that bad.

> 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).

You have to run

  create-version repository--application_main/application

> 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 ?

Correct.

> >   (hack, hack, hack)
> 
> ok, ok, ok ;-)
> 
> >   arx commit -s "Useful hacks"
> 
> I assume the changes are sent to the local developer archive.

Correct.

> >   (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 ?

I think I want to hold off on this for a little while until we get
some experience with "send".  It would also be good to know if Robert
Collins has this problem, and how they fixed 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 ?

I think the "send" command will solve this.

> 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.

Odd.

Cheers,
Walter