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

[Kevin Smith]

Walter Landry wrote:
> Kevin Smith <address@hidden> wrote:
>
> Sorry for the delay.  I am in the wierd position where I can read
> email immediately, but sometimes not send email for days.

If everyone were always in that state, the world would probably have a 
lot fewer flamewars, and generally higher-quality emails. :-) However, I 
definitely feel your pain.

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

So the ArX archive registry would disappear. Any command that currently 
takes an archive name would now take a URL. At some point we could 
invent a simple alias system, but that can wait. Is that correct so far?

Lightweight branches. First, I think we need a different term, because 
other systems use that to mean a branch that's stored within the same 
repository, as opposed to creating a new branch by creating a new 
working directory (that contains that branch's repo). So I propose 
something like "remote branches" or "distributed branches".

I really don't know much about remote branches, so you'll have to design 
and perhaps implement anything in that area.

So how can we get from here to there? I'm a huge fan of incremental 
development, so I would really like to have a series of changes where 
the system is never broken.

Perhaps the first step would be to do the work described below. That 
would dramatically cut down the number of places that would need to be 
changed to reflect the big archive naming paradigm shift.

After that, could the remote branch work be done first (switching to be 
URL-based), without affecting other parts of the system? If so, that 
seems like a good first step.

Next I think we could allow existing commands and data files to accept 
and store URL's where they currently take archive names. Once that's in 
place, remove all cases where new archive names can be created by 
existing commands.

The final cleanup would be migration scripts to eliminate legacy archive 
registries, and switch any legacy archive names in data files over to 
the new URL method.

Does that sound about right?

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

Cool.

Kevin