[RFC] bzr.jrydberg.versionedfile

[John Arbash Meinel]

Goffredo Baroncelli wrote:
> On Wednesday 21 December 2005 15:44, Aaron Bentley wrote:
> 
>>Robert Collins wrote:
>>
>>>>Rolling back changes are also needed when we end up in situations that
>>>>there is no clean way out of; out-of-disk being one.  We want to leave
>>>>the history exactly as it was _before_ the modifying operation begun.
>>>
>>>
>>>This is more interesting - but just stopping cold would be fine, if we
>>>have maintained our invariant of 'all data is always valid all the
>>>time.'
>>
>>I agree on this point; there is no harm in leaving extra data in files,
>>as long as it is correct, and doesn't reference missing data.
> 
> 
> 
> Sorry, but I disagree; I don't understand the gain of having revision that we
> don't want or don't know to have: if we want this revision we fetch it; but if 
> we don't fetch then we don't need it.
> 
> The fact that for the weave, the things are so, in _my opinion_ is a bug, allowable
> only because bazaar is a young project.
> 
> Moreover I see some disadvantages to have revision not referenced. 
> 1) If we wont to know the changes related to a file, we can parse only the file; instead
> if we allow unreferenced revision, we have to intersect the revision related to 
> the file, which the ones "official".

I don't think there is a large gain here. A list of revisions officially
merged are small. And you always need to know what revision you care
about the changes. If only to annotate the current object.
Since knits contain the ancestry information for the file, all I need to
know is the current revision, and then all of those extra changes are
hidden.

> 2) if the project is a big project with many contributors, which pull from others
> contributors, we can have an explosion of the storage size.

Not really. You rarely will get anything that you wouldn't get anyway.
The only things that are 'wasted' are merges/pulls which you then decide
that you don't want.
'bzr' doesn't support the "I want a rollup of all those changes, and
then forget about all the individual revisions that made them." It *can*
support them by having ghost revisions, etc.
And you could always do:
cd other; bzr diff ARGS > ../foo.patch
cd ../mine; patch -p0 < ../foo.patch

> 3) if we want to remove a revision ( because contains reserved data, and we want to publish
> the repo  ), we have to check carefully every merge, on order to avoid this revision
> 
> I agree that may be useful to have data not referenced, but only if we want, and not as
> (dark) side effect of an operation.
> For example: if we add an option like "--full" to the pull command in order to fetch all
> revision, for me is ok; but if we don't use this switch bazaar don't have to download
> the unreferenced revisions. 
> I don't like the idea that in the repository there is something that we don't want or things 
> which we don't know to be.
> 
> My 2 ¢

Well, I'm not sure about Johan's specific implementation, but it would
be possible to supply the 'Knit.join()' command a list of revisions
which I think I'm going to be interested in. And it will only bring
those in.
If it turns out that I don't want them (I do 'bzr merge' and then
realize I don't want those changes), are you asking for them to be deleted?

I think the risks of having a common delete operation outweigh the
simplicity of leaving stuff there, since most of the time you will want it.

If it is simply "I want to sanitize everything which has not actually
been added to this branch", we would want a command like that anyway.
Because a repository is going to share knits, and if you make something
public, you may need to sanitize it.
But this would be more of a "take what I have, and generate a new
branch, stripping out all unreferenced information". It would be an
occasional pruning, not a common operation which might delete stuff.

> 
> Goffredo
> 

I think greedy behavior is a sane default. As long as we provide a way
to create a standalone branch which has been sanitized.

If you really want to merge someones changes, without merging their
history, use diff + patch. The whole point of bzr is that it will keep
track of the history, and let you know that it doesn't need to merge
again, because it has already merged those changes. It is possible that
you could have limited history branches, which keep some sort of
reference saying that they merged these revisions, but don't actually
know anything about them. I don't think bzr is planning on supporting
them, and would need pretty strong use cases to do so.
Checkouts and repositories fix most of the use cases for why people want
that sort of behavior.

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/87a3d7e1/attachment.pgp