[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Arx-users] ArX best practices

From: Walter Landry
Subject: Re: [Arx-users] ArX best practices
Date: Tue, 11 Jan 2005 21:20:11 -0500 (EST)

Kevin Smith <address@hidden> wrote:
> 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,
I assume you meant "mirror" here.

>     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

The only real difference between these two modes of operation is that
you have a local copy of my archive.  Whether this is a good idea
depends on whether you have good network connectivity or lots of hard
drive space.

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

I don't quite understand here.  In both cases, you have your own
private archive with local modifications.  ArX is not like monotone or
darcs, where you can make a copy of an archive and commit into it.
Rather, you fork development into your own 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.

I think that the tla wiki has some of this, but a lot of it is tla-specific.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]