Bzr development stopped

[Massimo Manca]

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


-- 
Massimo Manca

-------------- next part --------------
A non-text attachment was scrubbed...
Name: massimo_manca.vcf
Type: text/x-vcard
Size: 324 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20121127/7f0c07f2/attachment.vcf>