How can one synchronize development between several machines

How can one synchronize development between several machines

Gustav W Delius -
回帖数：7

This is a question about CVS which is not specific to Moodle. But perhaps a Moodle developer knows the answer:

We have several developers here working on Moodle, each on their own machine. Only one of us (me) has write access to Moodle CVS. So all commits should happen through me. How can this be done?

At first I thought the developers would simply have to send me all modified files, I would drop them into my sandbox and then commit. However this would only work if both the developer and I updated our sandboxes at the same time to the same code. Unfortunately at SourceForge anonymous CVS and developer CVS are out of step. So if the other developer updates via anonymous CVS and then sends me his modified files and I drop them into my sandbox that is updated via developer CVS then some changes made in central CVS could get lost (and this happened to us once already).

平均分： -
回复Gustav W Delius

Re: How can one synchronize development between several machines

Ray Kingdon -
Why not do it the CVS way? - allow all your developers write access to the Moodle CVS. That's how it meant to be used (and it does work, that is). CVS does sort out multiple updates to the same file.

Scenerio: You change something in workshop/lib.php in CVS (which you have done). I'm working on my local copy of workshop/lib.php which hasn't got your changes in it (which I have done). I try to commit my new version, No, says CVS I can't do that, there's a version number problem. I then do a cvs update on my file and, bingo, I can then commit it. The CVS version now has your changes and my changes. Works 95% of the time, when it doesn't, there's a conflict (we're both altering the same lines of code) and the cvs update flags where the problem is in the code. (I then delete your changes... no, no, only joking big grin.)

Now that's how I think CVS works, please tell me if I'm off beam here.

平均分： -
回复Ray Kingdon

Re: How can one synchronize development between several machines

Gustav W Delius -

Thanks Ray, that is indeed how CVS works between developers who have developer access to it. But for understandable reasons Martin doesn't like to give out developer access to too many people, he wants me to be responsible for all commits from our group.

One possible solution for our group would be to install our own personal CVS server on which we share our development code. The question is how I can keep that CVS repository for our group synchronized with the Moodle repository. Perhaps our group's server should not be running CVS but something more modern that has special facilities for this kind of thing?

平均分： -
回复Gustav W Delius

Re: How can one synchronize development between several machines

Martin Dougiamas -
Core developers的头像 Documentation writers的头像 Moodle HQ的头像 Particularly helpful Moodlers的头像 Plugin developers的头像 Testers的头像
When I suggested local development, I was thinking that you would have a central development machine with your CVS copy of Moodle that all the local developers would be working on at once, obviously keeping in touch about what they are working at that moment (see XP programming).

This is what I do with Shane when he works with me here at Casa Moodle ... then periodically I or he updates or checks in files (using my CVS account) at sensible points in the work.

File conflicts are not a problem with editors like vim, because files are locked when opened for editing.
平均分： -
回复Martin Dougiamas

Re: How can one synchronize development between several machines

Gustav W Delius -
Ah, I hadn't thought of that possibility yet: all developers working in the same sandbox on a central machine rather than each having their own sandbox. That would indeed work.
平均分： -
回复Gustav W Delius

Re: How can one synchronize development between several machines

Penny Leach -
The way we do it is run a local version control system (we're using Arch which I really like) and make a lot of small commits to that, and then once we're ready to commit back to moodle cvs, update our copy, patch the files from arch's changesets, resolve any conflicts, test it, and then commit back upstream.

So that way (you wouldn't have to use arch, you could have a local cvs repository as well), you could have one person in charge of patching the checkout from moodle cvs and testing it and committing it back.

The other thing that you could do is share ssh keys in the sourceforge account. I only think that would work for a very small team (like ours) and you'd want to make sure the commit message had the name and email address of the developer it came from. This is essentially the same thing as having a shared sandbox really, you're all working using someone's ssh key in one place, whereas if you wanted to retain separate sandboxes, you could put your different ssh keys in the sourceforge account you're using to commit. In fact you probably would want to do the same thing with the commit message if you're sharing a sandbox anyway.

Also, another reason we're doing this with a local arch, is because we're developing against 1.4 ourselves but the work we're committing back upstream needs to be into HEAD, so sometimes patches don't patch nicely and stuff needs to be tested twice - once against 1.4 and once against 1.5.

Incidently, we found a really nice way to deal with .rej files from patches that don't patch cleanly - http://wiki.gnuarch.org/moin.cgi/Process_20_2a_2erej_20files
平均分： -
回复Penny Leach

Re: How can one synchronize development between several machines

Martín Langhoff -
Penny has described what we do quite well. Earlier, I had written a description of the alternatives -- but moodle.org seemed to be down so I sent it to Gustav directly.

So, for completeness sake, here it is:

There are three techniques you can use, depending on the size of the team, and the relationship you have with the main SCM repo (in this case, Moodle CVS).

Firstly, you can use shared sandboxes (over NFS or SMB). This is tricky and requires a lot of coordination.

Using per-developer sandboxes, the simplest one is to use the upstream repository (moodle CVS). This clearly doesn't scale, and makes the repo owner uncomfortable, but for teams of two or three working on separate modules or parts of the code, it is "good enough".

To minimize the impact if you are developing fast and furious, and don't want to break the tree, you can work in branches. But, again, this can make Martin Dougiamas rather uncomfortable.

The third alternative is to run a local SCM repository. CVS supports you running a "local branch" using the functionality known as "vendor branch" (see the vendor branch techniques described in http://cvsbook.red-bean.com/ ). We have used CVS with moderate success to run a local development branch of gForge.

The problem is, CVS sucks at merges. Not at single merges, but in any scenario with multiple and frequent merges, CVS will drive you to suicide. And having a local repository tracking an upstream requires merging a lot of code, very often. Dealing with CVS on the gforge development took a lot of work.

Arch is an alternative SCM. Using the techniques described in
http://wiki.gnuarch.org/ we are running a "local" Arch repo of Moodle. We develop fast and furiously there, committing early and often, and then we lump a batch of related patches and commit it to CVS.

When we re-merge from upstream, we tell Arch that the upstream
"contains" those patches already, and Arch won't flag them as conflicts. (CVS ain't that smart).

Still, a lot of the integration and merging requires manual procedures. If moodle was using Arch, all this would be much simpler. But for Arch to be a compelling choice for Moodle development, it will take some time.

Using either solution, you will be merging and remerging quite a bit. So conflict resolution is something you need to do with care. Arch helps a bit mor than CVS, but conflict resolution is _hard_. Good SCM systems help, but the core of the problem is hard.

In fact, one of the most useful tidbits we've found was the Emacs trick Penny refers to, and the 'wiggle' utility.

平均分： -
回复Martín Langhoff

Re: How can one synchronize development between several machines

Gustav W Delius -
Penny and Martin, many thanks to both of you. We will have a good look at Arch. What you describe sounds like exactly what we want to do.
平均分： -