Branches without working trees

[John A Meinel]

Robert Collins wrote:
> On Sat, 2005-10-29 at 16:02 -0500, John A Meinel wrote:
>> Attached is a patch which allows for branches which do not have a
>> working tree. It is also available as a branch here:
>> http://bzr.arbash-meinel.com/branches/bzr/no-working-tree/
>>
>> I think this makes sense for published repositories.
> 
> I agree, so much so in fact, that I did almost exactly the same thing in
> my branch today too. From my NEWS file:

I saw that on your bazaar-commits as well. It's kind of a shame we both
spent the time working on it.

> 
>   IMPROVEMENTS:
> 
>     * 'bzr diff' now returns 1 when there are changes in the working
>       tree.
> 
>     * 'bzr push' now exists and can push changes to a remote location.
>       This uses the transport infrastructure, and can store the remote
>       location in the ~/.bazaar/branches.conf configuration file.
> 
>   INTERNALS:
> 
>     * WorkingTree.pull has been split across Branch and WorkingTree,
>       to allow Branch only pulls.
> 
>     * commands.display_command now returns the result of the decorated
>       function.
> 
>     * LocationConfig now has a set_user_option(key, value) call to save
>       a setting in its matching location section (a new one is created
>       if needed).
> 
>     * Branch has two new methods, get_push_location and
> set_push_location
>       to respectively, get and set the push location.
> 
> 
>> This means I moved "WorkingTree.pull()" back into Branch.
> 
> I split this instead - workingtree responsibilities stayed on the tree,
> branch ones moved to the branch.

The only thing the working tree really does is do a merge_inner() after
the revisions have been pulled. But that is your prerogative.

> 
>> I also implemented "cmd_push" as a form of pull() with the targets
>> reversed. To do this, I have pull() check to make sure that if there is
>> a working tree, the branch is local.
> 
> I avoided this check by doing the split I mention above : my cmd_push
> just opens (or creates) the branch.
> 
>> I also allow for a separate .bzr/x-push-target location. For some
>> working models, you might have a default upstream, with a different
>> default push location.
> 
> Some differences here - it didn't make sense to me that the push
> location would be preserved by branching, so I stashed the push location
> in ~/.bazaar/branches.conf. I plan to make policy prefixes cause the
> branch name (i.e. the dir, or the manually set branch-name file
> contents) combine with the push_location for a policy prefix (i.e. a
> wildcard match in the config) to create a (hopefully) unique target.

It isn't preserved by branching. Not all files in .bzr/ are preserved.
For example "parent" is not preserved. .bzr/x-push-data or
.bzr/x-rsync-data are not preserved (or should not be :)

I think it makes a lot more sense keeping it inside the current working
branch.
Otherwise renaming the directory means you lose your push target.

I think you would agree that .bzr/parent makes sense in the branch, I
would say the push location would as well.

> 
>> This is getting pretty close to having branch aliases, which might be a
>> better solution.
>>
>> The doubt in my mind is why I made it a separate patch.
> 
> I think push is a must :). Right now, I'm working on making Aarons rsync
> push decorate the cmd_push in bzr, so that both can be used. My cmd_push
> is pushed to integration as I think its definately the right way -
> though your working tree presence detection method may be useful in its
> own right. I've also pushed a fix to bzrtools for the fallout from
> changing diff to return 1 when there are changes.

Obviously you think your version is correct. You wrote it :)
I'll look in on it, and see what you have done.

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/20051029/15a9304e/attachment.pgp