Re: [Arx-users] ArX and simplicity

[Walter Landry]

Kevin Smith <address@hidden> wrote:
> Walter Landry wrote:
> > Kevin Smith <address@hidden> wrote:
> >>>The solution to the first problem is to make the use of archive names
> >>>much more implicit.  One possiblity would be to get rid of the default
> >>>archive and instead use the archive of whatever project tree we are
> >>>in.
> >>
> >>This is an area of ArX that I don't yet understand. More explanation
> >>would be helpful.
> > 
> > 
> > I am confused about what you are confused about ;)
> 
> You mentioned "default archive". That's a per-user setting, right? Then
> you say that we could use the archive of whatever project tree we are
> in. I hadn't thought it through to know that each tree *has* an archive,
> but it makes sense that it does. In which case, why would it ever make
> sense to use the default archive if you are already in a tree? The only
> time I can see for using the default archive is if you're not in a tree
> when you give the command.

I have considered going even farther than that.  I was thinking of
allowing you to specify only a revision number when inside a tree.
Something like

  arx diff ,13

would diff the tree against revision 13.  With the hashes for
revisions, you may not generally have separate branches.  In that
case, you could specify as much of the hash as needed to uniquely
identify it.  Outside of the tree, there is no longer a default
archive or branch, and you have to manually specify everything.

It starts to look a lot like monotone.  Monotone has the moral
equivalent of the "-A" option, and does use archive names at all.
They can get away with this because they do not support lightweight
branches.  So they don't worry about linking between archives.

Hmm.  Lets look at the commands and see how they would be affected.

  Unaffected:
    add, mv, param, rm, tree-lint, edit, ignore, property, dopatch,
    mkpatch, inventory, tree-root, redo, undo, archives, make-archive,
    update-listing

  Mostly used within the tree with the current branch, so mostly unaffected:
    commit, diff, log, file-diff, file-orig, file-undo, tree-cache, fork,
    merge, replay, missing, tree-branch

  Somewhat dangerous, so it is probably best to require a full
  specification anyway:
    break-lock, delete-branch, delete-revision, history

  Will usually need a full specification where it did not need it before:
    get, init, tag, export, get-patch, patch-report, archive-cache, sig,
    library

  Will usually need a full specification and usually needed it anyway
    browse, mirror

For someone doing purely local work, they will now have to specify an
archive for the common operations "get", "init", and "tag".  That
doesn't seem so bad.

> So I guess I wasn't actually confused about ArX until you wrote that :-)

There is still a fair amount of historical baggage in ArX =:o

> > With hashes for archive names, the only restriction would be that they
> > are not exactly 64 characters long.  However, prefixing with a colon
> > would disambiguate it from a branch name.
> 
> My proposal was to allow aliases NOW, rather than waiting until archives
> use hashes. It's a highly valuable feature, even if slightly crippled
> such as by requiring a prefix character.

Actually, I don't think we really need a prefix.  If you create an
alias with the same name as an archive, it should be simple to detect
that.  I have so many other things to work on, but if you give me a
patch, I will incorporate it.  This can be implemented before archive
hash names, and should transfer cleanly once that arrives.

<snip>
> > However, I don't think that using a different character will really
> > solve the problem.  The real problem is that you can type 
> > 
> >   arx browse foo
> > 
> > and you don't know whether you meant "foo" to be an archive or branch.
> > Using a different separator won't help, because you forgot to put it
> > there in any case.
> 
> Maybe this will all become clear to me when I read the newly-revised
> documentation. I just remember being very frustrated trying to do
> "browse", "get", and "merge" commands and getting vague error messages
> back. Then, when I discoverd that foo and foo/ refer to two completely
> different things, I freaked out. That's the main thing I think needs to
> be solved.
> 
> On an esthetic level, I don't like that a/b/c.d,e is really parsed as
> [a/b][c.d,e]. It just looks like c is part of a/b/c.

Using "#" as a separator and requiring the archive name should solve
this problem.  Then "foo" and "foo#" will mean the same thing.

> > Some commands are recursive, so they can take an archive, a branch, or
> > a revision.  "browse", "update-listing", and "mirror" are some.  Using
> > something like the -A argument, where you are then not allowed to
> > specify the archive with the branch, might work.  So browse would be
> > 
> >   arx browse -A archive branch.subbranch,revision
> 
> I definitely don't like this. I was thinking more like:
> 
> arx browse archive/branch.subbranch,revision
> 
> arx browse -A archive
> 
> ...or...
> 
> arx browse archive
> 
> arx browse -B archive/branch
> 
> Not sure if that makes any sense, but it's what I was thinking.

I don't like having two ways of doing things.  It just confuses
people.  I am gravitating towards

  arx browse archive#branch.subbranch,revision
  arx browse archive
  arx browse archive#

where the last two commands do the same thing and "archive" can be an
alias.

Cheers,
Walter