[Top][All Lists]

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

Re: [Arx-users] Repo format take II

From: Kevin Smith
Subject: Re: [Arx-users] Repo format take II
Date: Sun, 18 Dec 2005 23:31:03 -0500
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051011)

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.


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.


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

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

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


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


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


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



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.


reply via email to

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