bzr-gtk vs. QBzr

[Alexander Belchenko]

Colin D Bennett пишет:
> On Thu, 26 Feb 2009 21:47:57 +0200
> Alexander Belchenko <bialix at ukr.net> wrote:
> 
>> Russel Winder пишет:
>>> Alexander,
>>>
>>> On Thu, 2009-02-26 at 19:08 +0200, Alexander Belchenko wrote:
>>>
>>>> I don't understand your concern about garbage collecting. If you're 
>>>> merge your feature branch to mainline all revisions will go there.
>>>> If you do uncommit in the branch inside shared repo the garbage will
>>>> stay there anyway. It seems like only stacked branching for feature
>>>> branches is real answer today.
>>> I am not sure I understand the feeling either, it is irrational and
>>> based on emotion :-)
>>>
>>> The scenario I have in mind is:
>>>
>>> 	Take feature branch
>>> 	Do some experimentation including commits
>>> 	Abandon branch as a failure
>>> 	Delete branch
>>>
>>> As I understand various comments made some months ago on the list this
>>> will leave garbage in the shared repository that cannot be removed.
>> This is true and not true in the same time.
>>
>> bzr has built-in garbage collector called "branch", sometimes known
>> as "init+pull". Or even "push"; it's does not actually matter.
>> All you need is: periodically create new empty shared repository
>> and branch there your old branches. This will effectively filter out
>> all garbage and in the end you'll have new shining repo.
>> I'm sure any Linux hacker can write the script for this maintenance
>> stuff in 5 minutes. Or may be even in 4. Someone even can spend
>> 5 more minutes to write bzr plugin to do this stuff.
> 
> That's really a kludge and will require 2X the disk space -- also might
> be more wasteful of time:  If all garbage is new since the last GC run,
> then the garbage collector can consider only that new data and not have
> to copy tons of old revisions that are clean.

Try to run `bzr pack` for shared repo and you'll see 2x more space allocated very easily.
New data, old data -- does not matter either. You have to check everything anyway.

Again, if you have tightly packed repo into 1 big pack -- you have to copy relevant
revisions and omit garbage.

So I'd say your counter-arguments are not valid in generic case.

> Also, simply branching into a new shared repo is more complex than a
> new user might think, since if you want to preserve all the
> submit_branch, push_branch, parent branch, etc., you have to manually
> reset it after branching, which is annoying.  (That script you speculate
> could be written would just have to deal with that.)

That's why I told about plugin. Smart plugin can copy this info easily.

But anyway, the only one answer on your concern: use stacked branches.
They are don't use shared repo, so no garbage accumulated there.