Bazaar as Subversion replacement

[Nicholas Allen]

> This is pretty complicated to do properly.
>
> A stopgap would be to have a precommit hook that fixed the line endings
> whenever you committed.  Would that kind of solution be acceptable?
>   
Currently this is easy in svn and I think there would be too much chance 
that a developer doesn't set this up properly. Wouldn't each developer 
need to do this themselves? So actually I doubt this would be a viable 
solution. I think the VCS needs to support this feature as easily as 
possible because cross platform development is a very common situation. 
Unless it is as easy as Subversion's implementation there is no way we 
could migrate without this. It is the number one show stopper for us.
>   
>> 2 No support for tags.
>>     
>
> That doesn't seem like a fair complaint, given that SVN doesn't support
> tags, either.  Martin is working on proper tags, but you can always do
> it the way SVN does.
>
>   
The difference is that svn stores all tags in the same repository. I 
guess you could use a shared repository and then branch into a Tags 
directory like SVN does. It probably shouldn't be so high on our 
priority list as we could even maintain a text file that contained 
mappings from tag names to revids so this is not a complete show stopper 
for us. I am also happy to hear that bzr has some implementations for 
the tags feature too.
>> 3 Inefficient 'bzr log filename' implementation.
>>     
>
> Point taken.  It's not too hard to fix (for filename.  directoryname is
> another case).  But people like me who don't use "log filename" don't
> find this limitation bothersome.  Is it possible that you're using "log
> filename" where "annotate" would work as well or better?
>
>   
One of the uses of this is to find out who last changed the file. In 
annotate we would have to go through the file to find the latest 
revision number. In svn we do svn log file | less and it completes 
immediately and we can see the most recent changes and who committed them.
>> 4 No way to ensure revision numbers don't change on a branch shared
>> amongst multiple developers (or pushed to by one developer from multiple
>> branches).
>>     
>
> I'm currently working on a new branch format, and plan to provide that
> as one of the features.  So a month or two is a reasonable timeframe.
>   

Cool! ;-)
>   
>> 5 Olive: No easy way to see differences in a graphical diff program such
>> as Beyond Compare.
>>     
>
> I expect it's a few hours' work, given an interested developer.
>
> It's easy enough with the difftools plugin, though.

Do you mean that this can already be done? One of the main uses we have 
for this is for a developer to review another developer's commits before 
merging a branch to trunk, for example. In TortoiseSVN we open the 
commit dialog and it shows every file that was changed. We can double 
click on a changed file to see what was changed and then select the 
check box next to the file name when we are happy with the changes. We 
do this for all files that changed and if they all pass review then we 
commit. Often we see mistakes during review and would like to edit them 
in place in the diff viewer (which meld and Beyond Compare bothe 
support).We would like the same workflow if we migrate to bzr. So it 
would be great if the gcommit dialog would work this way (it currently 
has the check boxes but double clicking on a changed file does not show 
the diff and olive's diff viewer is completly unusable too - which is 
why we would also want to run an external diff program).

Thanks,

Nick