Bzr development stopped

[Nicholas Allen]

On 11/27/2012 03:56 AM, Stephen J. Turnbull wrote:
> As far as tracking renames goes, there's a very simple strategy for
> guaranteeing 100% accuracy for git's inference algorithm: always
> rename (or copy, for that matter) in a separate commit, ensuring that
> git can do the matching at the "tree object" level by object hash.  Of
> course then you're not happy as a Java developer, because the rename
> happens in a different commit.
>
> With bit of fussing, either in the VCS itself or in the IDE you could
> ensure that such commits happen on a branch, which is automatically
> merged with the desired parent.  It will be a WTF for people who
> haven't seen it before looking at the history DAG.  Except for that
> glitch, though, this strategy should pretty much satisfy the needs of
> Java developers, since it's not the rename tracking per se that they
> care about at commit time, it's that renames be bound to the content
> changes.
That sounds like a complete nightmare! I would hate any system that 
worked this way. Simple recording of simple information that doesn't 
require extra branches etc is the only solution. It's not hard to record 
file renames into the history. Git disregards that information which is 
plain silly to me - there can be no downside to recording it whatsoever 
(even if Git wants to do intelligent stuff it can do both - it doesn't 
have to be one or the other). Git is just not a suitable version control 
system for Java development or any other kind of work where the names of 
file is really important. It might work accidentally but the algorithm 
will break down in some weird case and then all kinds of problems will 
emerge. I just don't want that kind of version control system for my 
java projects...