bzr 0.0.3 released

[Petr Baudis]

Dear diary, on Thu, Apr 07, 2005 at 12:58:35PM CEST, I got a letter
where "Markus F.X.J. Oberhumer" <markus at oberhumer.com> told me that...
..snip.
> Also it would be nice if it were possible to do "bzr mv" after the mv
> has already happend (darcs does allow this).

And bzr rm should remove both still existing files (possibly removing
them along the way) and already gone files. Baz requires the first, CVS
requires the second and it's a mess; both is useful in various cases.
In Baz it's annoying whether you mistakenly remove it with mv instead of
bzr rm (you need to do stupid touch file && baz rm file) or when some
other tool wipes the file out and you want to "acknowledge" the removal.
In CVS it's annoying when you remove files by glob, shell can't expand
it when there is really nothing to glob anymore. ;-)

> And somewhat related to mv, I think that automatically removing files
> from the repo is a really bad idea. Think of "vi a", "mv b c", "bzr
> commit". "mv b c" should have been "bzr mv", but now b has silently been
> removed without any warning. No file should get added without "bzr add",
> and none removed without "bzr remove".

Usually the systems refuse to commit from tree which is not "up to
date". Here it would involve at least checking that all the files which
should be around indeed are around. Actually, I'm not sure if there can
be several tree instances of a single branch (CVS/SVN-like), or whether
each "checkout" will create a new branch in bzr (BK-like). In any case,
there should be something like 'bzr update' which brings the tree in
sync with the branch (only in the second case it should be maybe named
differently).

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