Re: [Arx-users] The Future (long)

[Walter Landry]

A few more things that occurred to me:

If a revision is at the start of a no-history branch, then we need to
mark it so that ArX knows there is a cached revision there and to
start over for skip-deltas.  We can add a "0" to the end.  This uses
all 31 characters available on some systems.  (But see later.  I may
get rid of skip-deltas).

CONTINUATION files suggest to ArX where to find possibly remote
revisions.  It is needed for tags and no-history branches.  Those
would be in the revision patch directories, and there would be a
command to update them.

We can decide a microbranch is no longer interesting, even if it has
not been merged ("arx terminate" has a nice ring to it).  We do this
by creating a directory with the hash of that terminal revision and a
"T" at the end.  So the directory would look like

   aaaaaaaaaaaaaaaT/

The "T" at the end is needed to disambiguate the revision from a
starting revision.

The rest of this email is about the problems skip-deltas cause for
merging and alternatives to skip-deltas.

If we apply just one patch, users will expect to be able to read the
log for that imported patch.  They will also want to find out exactly
what the patch did.  We don't have a way of referencing the patch by
name, since all of the url info is stripped from the log.  Moreover,
since we are not duplicating logs in the tree for space reasons, that
means the repo has to have the patch.  But skip-deltas require us to
store multiple patches in the repo.  This will confuse and annoy users
(Why is that patch there?  I never asked for that patch!).

Next, suppose that we have a local repo and local project tree.  We
merge that local tree with a remote repo.  For the same reasons as
above, we should put all of the new patches into the repository.  To
be concrete, suppose with the picture that I had before

>      aaa   (0)
>   /       \
>  |         |
>  |         |
> bbb (1)    |
>  |        eee (1)
>  |         /
> ccc (2)   /
>   \      /
>     ddd     (3)

aaa, bbb and ccc are stored on our local repo, and aaa and eee are
stored on the remote repo.  When I merge, should I automatically add
aaa->eee to the local repo?  What if eee is a no-history branch?  What
if bbb is a no-history branch?  This will end up pulling in a lot of
patches that the user may not particularly interested in.  They made a
no-history branch precisely because they did not want to be burdened
with the whole history.  Merging with a partially related branch
should not bring all the history over.

So now I am thinking of not using skip-deltas.  The simplicity of
having each patch really be just the link from one revision to another
is quite appealing.  <brain dump> Moreover, with that design, you
don't need to "fork" to make a no-history branch.  If you commit to a
repository that does not have ancestors, then ArX will automatically
create a cached revision.

In general, ArX would do all of the repo maintenance to ensure that
the repo is self contained and has reasonable performance.  I still
don't like repo caches, but skip-deltas might still be useful.  ArX
could create a skip-delta every time that the distance from a previous
skip-delta is greater than 32 patches.  Every 1024 patches it could
create a larger skip delta.  This would also be specific to a
particular repo.  So if the master repository has skip deltas at
revisions 32, 64, etc., but you branch from revision 45, then you will
not have any skip deltas until revision 77.  These skip-deltas would
also be created during repo syncs.

These skip-deltas would be single files in the database.  They would
only be used when creating revisions, not when comparing the
differences between two revisions.  They would be named after the
starting and ending revisions, and would be appended with an "s" to
denote a skip-delta.  For example,

  aaaaaaaaaaaaaaaZZZZZZZZZZZZZZZs

Also, we would proabably need a way to mark cached revisions, since
forked revisions are no longer special.  We could just use the name of
the revision followed by an "f" to denote "full".

There would still be named branches for those who want them.  Those
would be created with the "fork" command (perhaps renamed to
"branch"), and always create a cached revision.  Merging would
copy over enough patches to make closure.  That is, with the previous
example, if eee is in a branch, the merge would pull in
aaa->bbb->ccc->ddd.  You could independently copy over patches with
"propagate" (as in monotone, although it would not attempt to merge).
If you want to just move all of your patches into a single branch,
then you propagate everything to that branch and delete the old
branch.  If the main branch is fully merged up with the branch, this
would be a null action.  ArX will be smart enough not to copy things
it doesn't need.

This also raises another issue.  If I sync, who signs those patches?
What if, once I see them, I think they are junk?  I might forget to
delete them.  If I merged and then committed, then I am, in some
fashion, assuming responsibility for those patches.  But not if I
never merged them.

But what if I did like them?  Do I have to do something special to say
so?  So I would say that syncing repos just copies signatures, while
merging with another repo will make you sign the merged-in revisions.

<\brain dump>

Cheers,
Walter