Bzr development stopped

[Chris Hecker]

I actually agree with this, unless a) there are bugs that need fixing,
and b) there are features that need implementing.  I don't run into many
bugs, so I don't personally worry about a, but I have a lot of features
I hope will get implemented eventually (large binaries, nested trees,
partial checkouts, etc), so I worry a lot if there's not a critical mass
of development progress for b.

Chris


On 2012/11/27 11:48, Massimo Manca wrote:
> This is not a reply to Chris, I used this message only to send my
> general reply.
> 
> Why are there so many people worried about the Bazaar status of
> development? I use also other version control applications, mainly git
> and bazaar too. Seems to me that Bazaar is stable and well done, better
> then other vcs in some features and worst in others but it is very stable.
> I think also that too frequent releases (if they aren't bug fix
> releases) may be not so good because it means that the application
> complexity is growing and I don't think we need a too much complex vcs.
> In my opinion this is also a problem about git development.
> 
> May be that 2 official releases every year and 2-3 more maintenance
> releases should be the best situation for a stabilized vcs.
> What do you think?
> 
> Il 27/11/2012 19:01, Chris Hecker ha scritto:
>>> 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.
>>>
>>>
>>>  
>>>
>>
> 
>