[MERGE] Fix warning on working trees during push

David Clymer david at zettazebra.com
Sun Jan 15 15:34:06 GMT 2006


On Sun, 2006-01-15 at 13:44 +0100, Matthieu Moy wrote:
> jblack at merconline.com (James Blackwell) writes:
> 
> > As people are aware, bzr currently complains about pushing working trees.
> > This is consistantly interpreted as attempting to push has broken
> > completely.
> >
> > bzr: WARNING: Unable to update the working tree of:
> > sftp://sivan@mercury.linuxguru.net/%2Fhome/sivan/public_html/home-user-backup/
> >
> > This changes the warning to: 
> >
> > bzr: WARNING: Working trees are no longer updated. 
> 
> IMO, bzr not updating the working tree is a major problem, which
> should be solved instead of being hidden.
> 
> I'll give a simple example : I'm working on two machines, say W (work)
> and H (home). H is a personal machine that can't easily be accessed
> from outside (so push from H to W is more conveinient than pull from W
> to H). Now, consider the following scenario:
> 
> 1. I work on W, do some local modifications, and forget to commit.
> 2. I go back home, bzr pull, hack locally, commit.
> 3. I push to W.
> 4. I go back to work.
> 
> Now, my working tree on W contains some local modifications (the ones
> I forgot to commit). However, "bzr status" or "bzr diff" show me
> something completely different: the local modifications, plus all the
> work done at home. I have no easy way to distinguish the local
> modifications and the work done at home. Basically, the modifications
> I forgot to commit are lost.
> 
> There are tons of variants of this scenario, like
> 
> 1. I go back home, bzr pull, hack locally, commit.
> 2. I push to W.
> 3. I go back to work.
> 4. I forget to "bzr revert"
> 5. I hack locally
> 
> The precise reason why I like revision control systems to work on
> multiple machines is that it avoids data loss when you forget to
> commit (have you ever worked on multiple machines with email + tar.gz
> as the only transport mechanism? :-) ).
> 
> I think bzr should not create the working tree if it doesn't exist
> already, but if the local tree exists, it should definitely be updated
> (what's the point in having a working tree, if it's not kept up to
> date with the RCS data anyway?).

I strongly agree. 

Perhaps I want to version my website. I'd like to be able to code and
test on my laptop and just push to my webserver, rather than having to
push, then log in and revert every time. 

Or perhaps I don't have a shell account on the webserver, just (s)FTP
access. I would like to have the working tree as well as the revision
info on the server as a backup for the versioned code on my laptop, but
I don't have any means by which I can revert the remote tree. Actually,
It's more likely that I just don't know how.

In any case, requiring the extra step of reverting to get an updated
working tree _feels_ like I'm working around something that isn't
working correctly - regardless of what technical justifications for it
are.

-davidc

-- 
gpg-key: http://www.zettazebra.com/files/key.gpg
-------------- 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/20060115/ab9ca6a5/attachment.pgp 


More information about the bazaar mailing list