Branches without working trees

[John A Meinel]

Robert Collins wrote:
> On Sat, 2005-10-29 at 22:19 -0500, John A Meinel wrote:
> 
>> Some comments on your changes:
>>
>> In cmd_pull() you set the parent *before* you connect to the remote
>> branch. Which means if there is a typo in the command, it will remember
>> a bad branch name. I think it would be better to do it after a
>> successful pull, as it used to do.
> 
> Done, for push and pull. That was a snafu when I moved --remember out of
> the working tree logic, following a conversation with Aaron last week.

Good.

> 
>> In my version of push, it would test to see if it was possible to update
>> the working tree (or if one did not exist).
>> This meant that you could push to a network share, or just to another
>> branch on the same machine, and it would still update the working
>> directory. I think this is useful, rather than just outright forbidding it.
>> One problem with not updating the working tree is that we currently have
>> no way of doing it correctly.
> 
> I agree that you may wish to update the tree, or not. I suggest that the
> right way to do this is to use 'tree.pull()' on the tree you want to
> update - all the code is there. To do this in cmd_push, its as simple as
> trying to get the working tree for the branch, and falling back to the
> branch. This will need your heuristic for having the tree accessible or
> not. 

Sure. I was doing that inside Branch, but I suppose you could do it
outside of it as well.

> To be clear - I'm not claiming that the code I wrote was fully
> correct with respect to the working tree management. Not having the tree
> has a number of negatives - it may confuse people, .bzr is hidden, there
> is no README etc. But it also has a number of positives - its faster, we
> dont need to worry about differences in capability, and I hope that most
> folk that need the branch to be accessible over the web will install
> bzrweb or some such.

I'm not sure I follow all of your arguments here, we are talking about
*not* having a working tree, right? Which means that:
.bzr is not hidden, it just doesn't exist. My implementation of branches
without working trees is to just put "branch-format" into the main
directory. That way nothing is hidden (especially considering I never
figured out how to get apache to show .bzr)
I agree having 2 formats may confuse people.
The README is also directly exposed.
I'm not sure what you mean by "need the branch to be accessible over the
web". Are you talking about the content?

> 
>> "bzr revert" will change the working tree into the last revision, which
>> is close to correct, but if there were any uncommitted changes, they
>> would be lost (and you can't just commit, because that would revert all
>> of the other changes). The best you could do is a "bzr diff -r ???"
>> where you have to remember what ??? the tree was before it was pushed into.
> 
> ?! I dont get this. bzrtools push command does not preserve uncommitted
> changes either - the branch that is pushed too may have the working tree
> not match the last commit, but it is not used in 'bzr branch.'

That is because bzrtools push (and my rpush) just use rsync to mirror
the current working directory. That (in my mind) was a limitation of the
implementation. I believe for both of them, if you had uncommitted
changes, they would get pushed up (except they both check for a clean
tree first).
> 
>> I'm not sure that "bzr push" should create the remote directory if it
>> doesn't exist. Maybe. It can be nice as a first step for publishing
>> things. But it also means a typo could go wrong. Perhaps it could do it
>> if you supply a flag. "bzr push --create".
> 
> 'rmdir' is quite easy :). I've added a --create-prefix flag though, to
> allow creating much deeper paths. I create the final path always,
> because it seems nicer to me - much the way that 'branch' creates its
> output dir.

I think this is one of the differences in our thinking. I think of push
 as though it should be like pull, you think of it more that it should
be like branch.

I would rather see branch get remote working-tree-less support. So that
you could do:
bzr branch --no-working-tree here sftp://published/
And from then on, you would be able to push into that branch.
But it is arguable as to which command has this function. push is
certainly one of the possibilities.

> 
>> It looks like you merged in the diff changes, as well as the
>> set_user_option changes all into one patch. Not a big deal, but its nice
>> when changes are focused on a single change.
> 
> Indeed. However, I started with a test for push, and recursed back from
> there writing tests and code until I had the feature working - I didn't
> really know just what would be needed until I was done - and committing
> a hunk or two randomly would not have reflected what I actually had
> tested.

I suppose it is arguable whether each commit should pass the test cases,
or whether it should be a self-contained change.
I feel like a mainline (and maybe an integration branch) should act like
the former. But for a development branch, I prefer the latter. That way
the actual changes are obvious, and you can revert specific changes,
without accidentally reverting the wrong thing.

John
=:->

> 
> Rob
> 


-------------- 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/20051030/026aa4dd/attachment.pgp