bzr 0.0.3 released

[Petr Baudis]

Dear diary, on Thu, Apr 07, 2005 at 10:32:12PM CEST, I got a letter
where Scott James Remnant <scott at ubuntu.com> told me that...
> On Thu, 2005-04-07 at 15:27 +0200, Markus F.X.J. Oberhumer wrote:
> 
> > Martin Pool wrote:
..snip..
> > > So you'd rather have an error if you tried to commit when some files had
> > > been removed?
> > 
> > Yes, it should be an error whenever a file has vanished without an 
> > explicit "remove". This is not only for symetry with "add", but also 
> > essential given the importance of the archival nature of a SCM system.
> > 
> I disagree that an error should be given, the sky isn't falling ...
> simply providing a common status indication for "file is missing in
> working copy" would be sufficient:
> 
> $ bzr commit
> !   some-file.txt
> ?   other-file.txt
> M   third-file.txt
> A   new-file.txt
> 
> 
> Indicate to the user it was missing, and carry on as if it was there
> without any changes.  If the user wanted to remove it, they can always
> do "baz rm" and commit that next (likewise, they may want to add that
> extra file).

I actually think that by default it should take the safest way and force
the user to do bzr update (or whatever) first to get in sync with its
repository. But I agree that there is too much bikeshedding going on -
I'd like to get a red one but as long as it haves a roof, I'll gladly
let that to the actual worker getting to paint it...

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.