Bazaar as Subversion replacement
allen at ableton.com
Tue Jan 16 16:33:37 GMT 2007
> 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
> 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.
>> 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).
More information about the bazaar