[Top][All Lists]
[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
- Re: [Arx-users] Further thoughts on ArX and simplicity,
Walter Landry <=