Branches without working trees

[Robert Collins]

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.

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

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

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

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

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051030/d51eb79b/attachment.pgp