Bzr development stopped

[Chris Hecker]

> always rename (or copy, for that matter) in a separate commit,
> ... I don't claim this is actually satisfactory to people

Yeah, this is terrible, way worse than the "have to remember to rename"
"problem" in my opinion.  bzr's robust renames with renames of
directories and files intermixed with changes in a single atomic commit
is one of its main draws to me, I think it'd be crazy to give that up.

Chris



On 2012/11/26 18:56, Stephen J. Turnbull wrote:
> Talden writes:
> 
>  > In which-case I see what you mean, using git as the back-end might
>  > have very little impact on storage and it's only the meta-data that
>  > we'd miss.
> 
> The point of using the git storage system surely isn't storage
> volume.  If git ever performed better than other VCSes on storage
> volume it was purely an accident of using compressed files to store
> versions.  It's performance and robustness in maintenance because of
> the very simple data model used by the VCS itself.  No weaves or
> whatever attempting to optimize VCS operations.
> 
> 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.
> 
> The git storage system possibly could also be adapted to handle empty
> directories trivially, simply by allowing empty tree objects to
> exist.  I don't know about the ramifications of this in detail though.
> 
> I don't claim this is actually satisfactory to people who worry about
> git's technology, only that it should be possible to achieve the
> expressed goals.  Of course it's not at all pretty, and that matters.
> But I think worries that use of the git storage backend will cost all
> the nice features that Bazaar has achieved are misplaced.
> 
> 
> 
>