Scope of operations

[John A Meinel]

Robert Collins wrote:
> On Sun, 2005-10-23 at 09:43 -0500, John Arbash Meinel wrote:
> 
>> That does odd things when you tag a sub-project (say a library) with a
>> version. It generally has no meaning about the rest of the files, though
>> that may not hurt anything, how do you build a project with version 0.1
>> of libfoo, and version 0.1.1 of libbaz? (With arch we just put
>> everything into a different branch).
> 
> With the NestedTrees proposal, a by reference tree's revision id would
> be recorded in my tree's inventory for the tag. No problem :).

Well, when this was being discussed, it was trying to figure out
by-value. If we get by-reference, then yes, this is very clean.

> 
>>> But, I know that users often want to work on a small part of their code
>>> at once, and it follows that operations like log/revert/commit/annotate
>>> (and, if weave shows its potential, perhaps pull and merge), should work
>>> on the part of the branch they are working in. Yes, they can commit
>>> something that does not work, but they can always just commit the rest
>>> too.
>> log, revert, and annotate make sense to me. I'm concerned about "bzr
>> log" speed, right now it has to parse all of the inventory entries to
>> figure out what changed. I realize with weaves, this can be optimized to
>> just pull the table of contents. But "bzr log" in a subdirectory means
>> having to pull all of the tables for every sub-file.
>> Because it would probably be slow, I would rather require it to be
>> explicitly given.
> 
> So, if its not slow, you're ok with it :). There are a number of ways to
> address that, the easiest of which is probably propogating changes up
> from children during a commit - but, I think log could easily be full
> tree by default without breaking people :).

I think "bzr log" is one of the commands that are run a lot to figure
out what is going on. So I think having it be fast is desirable.

But yes, I don't have a big problem with it being restrictive by
default. Though it isn't how *I* would want it to work. :)


> ...
>> As far as having pull/merge be per subdirectory....
>> I think we can record the pull in the *.weave files, but we have no way
>> of recording it in the ancestry. I certainly don't think we would want
>> to set a "pending-merges" entry, since a future full tree merge would
>> then skip half of the changes, though otherwise it might conflict on the
>> other half.
> 
> Its really just a partial merge of a subtree - we would record the new
> file parents during the merge, and store that explicitly against the
> files in the resulting inventory.

Once we do partial merge / cherrypicking, where we can record per-file
what has been merged, I think this works out fine.

> 
>> Would you have pull or merge pull all of the changed texts, and
>> incorporate their values into the weaves, and then only "merge" the
>> changes for the current sub-tree? That is the only way I can see staying
>> somewhat consistent, so that a revision entry references all of the
>> inventory changes.
> 
> I think that that would make sense, though I don't think its necessary.
> 
> Rob

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051113/2c9b924c/attachment.pgp