[RFC] bzr.jrydberg.versionedfile

[John Arbash Meinel]

John Arbash Meinel wrote:

...

> 
>>I'm not sure it is a win, or even a need for it, and you are right
>>that we might end up in situations where there can be disagreements
>>between the index and the graph-file.
>>
>>~j
> 
> 
> Well, even with the above constraint that it is only about the actual
> branch, I don't know if you gain much. If the branch keeps track of "I
> am this revision", then any complete revision graph can give you the
> full ancestry for that revision.
> And if we change so that 'revision-history' is always the first parent
> along the history (so converging two branches actually means that one of
> them 'wins'), then a branch is defined purely by a single revision-id.
> All of its history is encapsulated in that single identifier. (tags may
> not be, though).
> 
> In general, I think revision-graph is a non-starter. Simply because the
> information is already available elsewhere.

I have to modify this statement for 1 possible use case. If you wanted
to have a limited history branch.

Specifically, if you wanted to create a branch which *thinks* that it is
a full branch, but doesn't actually contain some of the ancestry. At
present, I don't think there are any plans to support this. Considering
how much Martin has fought about not wanting Ghosts, though he accepted
because he wanted easy upgrades from Arch.

Originally, I wrote changesets such that they could present the revision
information, without the inventory or texts. Applying them would
effectively give you a complete ancestry, though some texts were
missing. (My changeset plugin still works this way, though it is very
out of date, and I haven't had much time to work on my changeset branch).

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051221/2598cefc/attachment.pgp