Bzr development stopped

[David Allouche]

On Tue, Nov 27, 2012 at 10:08 AM, Nicholas Allen
<nick.allen at onlinehome.de>wrote:

> 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...
>

I don't think you understand what Stephen suggested.

What he was talking about was a storage-level strategy for reliably
representing renames in git store.

He implied that this strategy could be implemented in a way that is
transparent to the user, both at commit time and when inspecting the
history with the proper high level tools. The separate commit for pure
rename would only visible when examining the raw history DAG.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20121127/0474716e/attachment.html>