Re: [Arx-users] Repo format take II

[Kevin Smith]

Walter Landry wrote:
> 1) Cached revisions.  These are directories named by the short hash
>    and sequence number N.

> 3) Skip-delta.  These are one-way patch files (no logs) named by the
>    short hashes of the beginning <hash A> and finishing <hash B>
>    revisions and a number N indicating how many patches the
>    skip-deltas encompass.  

At a glance, the formats of those directory names all look quite 
similar. Would there be value in naming them such that you could tell 
just by the name what kind of directory this is? Perhaps a leading 'C' 
or 'S'?

> 4) Terminal revisions.  These are empty files named by the short
>    hashes of the terminal revision, followed by the character T.
>
>    repo/branch/0/<hash>T

Just curious why the T is at the end rather than the beginning. I can 
imagine some possible reasons, but would like to know the real one(s).

I'm not familiar with the term "terminal revision". Could something be 
both a patch revision and a terminal revision at the same time?

> 5) Sequence revisions.  These are empty files named by the short hash
>    of the revision, followed by a "N", and then a number N indicating
>    the sequence number of that revision.
>
>    repo/branch/0/<hash>N<N>

Same questions as for terminal revisions.

> 6) Tag revisions.  These are directories named like patch revisions,
>    but inside there is log, log.sig, and URL.  The log file has all of
>    the hashes and directory locations for tagged branches.  It does
>    not have the hash of the revision.  The hash of the revision is
>    actually the hash of the log file itself.  The URL file contains a
>    serialized list of complete branch names for the tagged branches.
>    If the branch is stored inside the same repo, then the repo part is
>    ommitted.

Again, is there value in knowing it's a tag just by the directory name?

> ==========
>
> In order to make sure that I covered everything, I wrote up what
> happens when when Don Quixote and his sidekick Sancho Panza work on a
> project.
>
> So to start, Quixote creates a repo
>
>   arx make-repo --key "address@hidden" repo

Just to be clear, wouldn't a first-time user more typically specify 
~/arx/repo or /var/arx/repo?

> this creates the directories and files
>
>   repo/
>   repo/keys
>   repo/README
>   repo/dirhash
>   repe/pending/
>
> Now he imports a project
>
>   cd project_tree
>   arx init ../repo,project
>   arx commit -m "Initial import"

So (assuming what I said above) the init would more typically be:
  arx init ~/arx/repo,project

I'm not thrilled by the , separating two distinct entities. Both are 
just filenames, right?

Also, I would hope that the UI would allow a default repo so the user 
would only have to specify the project name.

> He creates more revisions.  When he commits revision 32, that also
> creates a skip-delta back to the first revision

I thought skip-deltas typically relied on the random creation of links. 
Would this actually be hard-coded at 32?

> When the number of patches from the beginning gets to 256, ArX creates
> the directory
>
>   repo/project.d/256

Any particular reason for 256 instead of 100 or 1000?

> and any skip-deltas encompassing it.  This only works if it is at the
> tip of revisions.  He works on some mildly experimental stuff, but it
> does not work out.  So he terminates that microbranch
>
>   arx terminate ../repo,address@hidden

Not sure about that command name, but that discussion can come later.

> which creates an empty file
>
>   repo/project.d/256/abcabcabcabcabcT

Oh, so a "terminal revision" is actually a "terminated revision". I was 
thinking terminal==leaf.

> Don Quixote's trusty sidekick, Sancho Panza, decides to branch his
> repo.  At first, he just mirrors the entire repo
>
>   arx make-repo panza_repo
>   arx propagate /home/quixote/repo panza_repo

Again, command name choice discussions can wait.

> which just copies everything over.  He periodically resyncs, and the
> dirhash files mean that he only has to list directories that have
> changed.  He hacks by getting revisions out of his own repo,
> committing, and merging.
>
>   arx get panza_repo,project project_tree
>   cd project_tree
>   <hack>
>   commit -m "cheaper, faster, better"
>   arx propagate /home/quixote/repo ../panza_repo
>   arx merge

So "propogate" would merge at a repo level? It's late and I'm tired so 
I'll assume I'm missing something.

> and all of the other revisions.  Sancho then tells his project tree
> about the branch movement
>
>   arx relocate ../panza_repo

Hmm.

(snippage)

Overall, I feel a bit overwhelmed by the UI in your examples. I suspect 
it's a combination of:

1. The example itself intentionally covers some unusual cases
2. The commands are different from ArX and every other SCM on the planet
3. Did I mention I'm tired?

Back to the actual topic: I don't have any other useful comments on the 
repo structure. Based on my tiny knowlege of such things, it seems sane.

Kevin