arx-users
[Top][All Lists]
Advanced

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

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


From: Walter Landry
Subject: Re: [Arx-users] Further thoughts on ArX and simplicity
Date: Mon, 01 Aug 2005 13:48:24 -0700 (PDT)

Kevin Smith <address@hidden> wrote:
> Walter Landry wrote:
> > Kevin Smith <address@hidden> wrote:
> > 
> >>>>
> >>>>An archive is be a collection of branches. Each branch is an ordered 
> >>>>collection of patches.
> >>>
> >>>
> >>>Right now, everything is ordered.  But with revision hashes, they
> >>>would become partially ordered.  That is inevitable if you are going
> >>>to allow two people to work independently on the same line of
> >>>development.
> >>
> >>Can you define "partially ordered" for me?
> > 
> > 
> > If you have three revisions A, B, and C, you might be able to say that B
> > and C come after A, but you can't say whether B comes before or after C.
> 
> Ah. Would it be accurate to say that *conceptually* a branch would be 
> partially ordered, but a branch *as stored in a particular archive* 
> would be fully ordered?

Not even within a particular archive.

> If not, how would you represent partial ordering on disk?

Revisions are referenced by their revision hash.

> With the current ArX format, there is effectively a "vector" of patches, 
> due to the ,nn directory naming. If you switch to hashes, would you 
> still represent a vector by listing the hashes in a text file somewhere, 
> or would you switch to more of a linked-list where each revision would 
> point to its parent(s)? Or both?

Each revision only has one parent.  For the archive format that I am
proposed, the parent is listed in the directory listing.  The current
format is like an array, where it is easy to skip forward 10 patches.
The new format will be like a graph, where each node links with its
parent.  A node can have multiple children, though.  Graphically, it
will be something like

  ,0-AAA
     ^
     |
     |
  ,1-BBB
   ^   ^
   |   |
  /     \
,2-CCC  ,2-DDD
         ^   ^
         |   |
        /     \
    ,3-EEE   ,3-FFF
      ^         ^
      |         |
      |         |
    ,4-GGG   ,4-HHH
      ^
      |
      |
    ,5-III


> >>I must have been thinking of revisions, since (I guess) patches wouldn't 
> >>have sequence numbers.
> > 
> > Now you are confusing me.  Both patches and revisions have sequence
> > numbers.  In mathematical terms, patches are the dual of revisions.
> 
> Oh. I was thinking that a "patch" was essentially a diff/patch file, 
> whereas a "revision" was a patch within the context of a branch, thus 
> having a revision number. But it looks like a revision can contain 
> multiple patches.

Now you are really confusing me.  A revision is the result of applying
patches.  Maybe a picture will help


         patches
         /  |  \
        /   |   \
       /    |    \
      /     |     \
     /      |      \
    /       |       \
    |       |       |
    V       V       V
   ---> ,0 ---> ,1 ---> ,2
         ^       ^       ^
         |       |       |
          \      |      /
           \     |     /
            \    |    /
             \   |   /
              \  |  /
             revisions

A patch moves you from one revision to another.

> I'm not a math/science guy, so "dual" doesn't really help.

You can also think in terms of calculus, where the revision is the
function, and a patch is the derivative of the function.

> I wish we had a wiki so we could have an easily maintainable glossary.
> 
> >>Hm. So given a patch that's already in a revision in my branch, and a 
> >>patch that someone sends me, how would ArX know whether or not that 
> >>patch was already in my branch? I thought that was how cherry-picking 
> >>got into this discussion, but I guess not.
> > 
> > 
> > ArX looks at the embedded name of the patch.  If you did something
> > like change the metadata, then you have a different patch.  Metadata
> > is important too.
> 
> What is the "embedded name"? Is that just the commit text? Or is it the 
> hash of the patch+metadata?

The hash, added after you compute the patch.

Cheers,
Walter




reply via email to

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