Scope of operations

[John Arbash Meinel]

Robert Collins wrote:
> On Wed, 2005-10-19 at 15:31 +1000, Martin Pool wrote:
> 
> 
>>:-)
>>
>>Here is a longer explanation.
>>
>>bzr versions the tree as a whole, not files or directories within it,
>>as cvs (and less so svn) does.  One reason for this decision is that
>>the main use is maintaining software packages where there are
>>dependencies between different files in the package, and we generally
>>want to get a complete snapshot at some point in time.
>>
>>The general working method is to edit some files, build and test the
>>whole tree, and then commit.  If you commit only a subdirector you're
>>recording a revision that's not what existed in your working
>>directory, and therefore not what was tested and reviewed.  That's
>>sometimes useful, but we don't feel it should be the default case.
> 
> 
> I'm starting to think that we are over emphasising the full tree aspects
> of our internals.
> 
> I think that (unlike svn) its important that we have a full-tree
> approach to what makes up a branch. That is, that the entire tree
> comprises the branch; that a file only appears once within the branch.
> The concept of subtrees going off in different directions in svn breaks
> my brain. Tags should be global to the tree for instance.

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).

> 
> 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.

I would still like "bzr log" to only display the last X revisions by
default (my shortlog plugin does exactly that). Displaying 1k revisions
by default is not very helpful. I suppose that is what leads people to
view logs in reverse, and pipe it into less. I prefer my logs to flow
with time (--forward), and limit it to about 1 screen worth of output
(--short, -r -10..), I can always dig deeper. However, I don't know if
this would confuse people in the long run.

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.

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.

> 
> Its certainly possible using configs (in some flavour) to achieve that
> between clearly separate projects, and there is a need in the future to
> allow easy separation and joining of trees. But I don't think that users
> should need to split their tree to get this convenience.

I think for read-only operations (bzr log, bzr annotate, etc), working
only in a sub-directory might be acceptable. And we should definitely
allow for partial tree commits. But I don't think they should be the
default.

John
=:->

> 
> Rob 
> 

-------------- 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/20051023/7a7afb10/attachment.pgp