Bzr development stopped

[Chris Hecker]

> He implied that this strategy could be implemented in a way that is 
> transparent to the user

But isn't this exactly analogous to the old svn argument that
copy+delete would work for rename and be transparent to the user?
Except, in practice, this stuff is subtle and it's really hard to get
all the edge cases, and I broke it constantly.  I haven't used svn in a
while, so maybe they've finally spackled over all the trouble spots, but
renames were a disaster for the many years I used it.

bzr's rename support is so refreshingly solid, I never worry about
renaming files, changing them to get everything working, renaming a
directory after I renamed and/or changed some files, renaming them again
when I change my mind in the middle of a fix, it all Just Works, which
is what you want from a sccs feature.

Chris




On 2012/11/27 08:54, David Allouche wrote:
> 
> 
> On Tue, Nov 27, 2012 at 10:08 AM, Nicholas Allen
> <nick.allen at onlinehome.de <mailto: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.
> 
> 
>  
>