arx-users
[Top][All Lists]
Advanced

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

Re: [Arx-users] Further thoughts on ArX and simplicity


From: Walter Landry
Subject: Re: [Arx-users] Further thoughts on ArX and simplicity
Date: Fri, 15 Jul 2005 18:16:23 -0700 (PDT)

Kevin Smith <address@hidden> wrote:
> Greetings all,

Sorry for the delay.  I am in the wierd position where I can read
email immediately, but sometimes not send email for days.

<snip>
> Walter:
> 
> You proposed this new naming policy:
> 
>    archive#branch.subbranch,revision
> 
> This sounded like a good idea at the time, and I still think it would be 
> a huge improvement. In my mind, it transforms one of the worst features 
> of ArX (confusing naming) into an advantage, because other systems would 
> tend to say something like archive -b branch.subbranch -r revision.
> 
> You also talked about assigning a GUID to each archive, as a tool that 
> would allow you to simplify the archive naming and relationships in 
> other ways. It's still not quite clear to me why a lightweight design 
> wouldn't work instead. Something like:
> 
> - Archives are identified by a URL
> - The user can optionally set up aliases for archives
> - "Lightweight branches" should generally be tied to aliases, to allow 
> following the upstream source if it moves

Hmm.  You've got me thinking.  For a lightweight branch, we could
store the URL of the main archive, but as a piece of changeable
metadata.  It would not be part of the revision, so it would not have
its hash computed.  It would just be lying around in the archive (in
the CONTINUATION file?), and tell you where this branch forked from.
It would just be an advisory thing, since in the end we would still
compute the hash of everything and check signatures.  But that is
really all that the archive names were anyway.  It could also be
changed when URL's change.

I think this would allow you to do everything you want, and still keep
me happy.

> With that, nobody has to worry about (be confused by) GUIDs. Everything 
> is simple and transparent. Archives don't have names, and and I think we 
> could remove the special case of "mirrored" archives. Mirrors would just 
> be a plain copy, at a different location. Users can set up aliases if 
> they wish, or they can use raw URL's.
> 
> Whenever possible, the archive should be inferred based on the current 
> working tree you are in. Whenever possible, the branch should default to 
> a reasonable value.

This is certainly good.  I have been meaning to do this for a while.

> Would you accept patches to move in this direction?

I think we are agreeing, but I am not sure that I am making sense ;)

Cheers,
Walter




reply via email to

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