[Arx-users] ArX best practices (was: Wedged another archive)

[Kevin Smith]

Kevin Smith wrote:
> Hm. Is it abnormal that I feel drawn to doing my merging in-place? Maybe 
> that's one of the main reasons I keep ending up wedged. It just feels 
> wrong to me to create a whole new tree just to pull in some changes. 
> Perhaps you could provide a little of the philosophy to help me 
> understand why in-place would be worse (or better) than the new tree 
> method.

I've been thinking more about this, and I think I see how I should have 
been using ArX for what I was doing at that point.

I wanted to do local work on the ArX source code. What I *did* was:

1. Fork a copy of the ArX repo locally
2. Make changes to that archive
3. Do an in-place get from superbeast to pull the official changes in

What I should have done (I think) was:

1. Get a copy of the ArX repo locally
2. Periodically do an in-place get from superbeast,
   so this local archive directly tracks the official archive
3. Create a local forked archive and do some work there
4. Periodically get changes from my local ArX "mirror" (that isn't a 
mirror, as discussed earlier today) into my working fork

This would ensure that I always have a good local archive (the official 
one). It also reflects the nature of the changes I was making at that 
time--most were temporary workarounds while waiting for features to make 
it into the official tree.

If/when my changes were superceded by official work, I could just 
abandon that fork. Using my original method, my "temporary" changes 
would be a permanent part of my ongoing local ArX archive.

Hopefully at some point we can build a "best practices" document 
describing how to use ArX most productively in a variety of common 
scenarios. Many of us who are relatively new to distributed development 
could definitely use the help.

Kevin