want commits to bound branch to update master branch's tree
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
I have a shared Repository, accessible by the file protocol (actually a Windows "file server"), created with the option --trees. We use the "Centralized" workflow ("lockstep"), all users use check-out/
This works ...
However, I used the "--trees option, when creating the central repro and *assumed* this means any commit will automatically update that central directory. Such, no-bazaar-users can read/browse the "latest" version of each file.
This however does not work!
Manually doing "cd <central/
When not using checkouk/commit, but using an (*assumed* almost the same) local branch, with a 'bzr push' them to the central repo, the tree there is updated!
Using latest stable windows version of bzr
>bzr version
Bazaar (bzr) 1.11rc1
Python interpreter: C:\Python25\
Python standard library: C:\Python25\lib
bzrlib: c:\python25\
Bazaar configuration: C:\Documents and Settings\
Central:
mkdir f:/Repositories
cd f:/Repositories
bzr init-repo --trees . # note the DOT
bzr init sprint
Dev:
cd ~/work
mkdir Proj;
cd Proj
bzr checkout f:/Repositories
cd sprint
touch aNewFile
bzr add aNewFile
bzr commit -m "the file is stored in the repro, but does NOT appear at f:/Repositories
summary: |
- bzr commit does not 'update' shared trees (in repository) + want commits to bound branch to update master branch's tree |
Changed in bzr: | |
status: | New → Confirmed |
importance: | Undecided → Wishlist |
tags: | added: bind |
tags: | added: check-for-breezy |
This is the expected behaviour (because of difficulties with handling conflicts): when pushing locally, the working tree will be updated.
when pushing remotely, the working tree will not be updated.
The push-and-update plugin will try to ssh in and do a `bzr update` for you when you do a push, but I don't think it works when committing to a checkout. And it requires ssh access to the server.
bug #325355 suggest that this should be possible when using the smart server, although I'm not sure how it would handle conflicts differently.