Bazaar as Subversion replacement
allen at ableton.com
Tue Jan 16 18:37:29 GMT 2007
>> Is this not high on the priority list? Is it really so hard to
> It means
> 1. We have to implement file properties.
> 2. We have to implement a new working tree format and a new repository
> format, including upgrade code.
> 3. We have to teach all our primitives that manipulate disk files to
> translate from authoritative-text to interpreted-text
> 4. We have to each all our primitives that read user files from disk to
> translate from interpreted-text to authoritative-text
> 5. We keep a cache of SHA1 sums of files. In most cases, the desired
> SHA1 sum would be the authoritative-text, but we might also want the
> interpreted text's sum.
>> I can't imagine this is only a show stopper for us. There
>> must be a lot of people who do cross platform development and this would
>> also prevent them from using bzr...
> The other thing is that not all Windows tools have
> broken line-ending handling.
That's true - but some tools require configuration to work correctly. If
developers forget to set this up then they make massive changes due to
incorrect line endings and that messes up merges and diffs.
> The other thing is that even if you're
> using broken tools, you should be fine if you use CRLF line endings
I don't think this is the case. I used bzr from work to edit a bash
shell script and then updated on my Linux box. The shell script no
longer worked because of the line endings. Bash gave all kinds of weird
errors and it took a while before I realized it was the CRLF line
endings causing the problems. Also Batch files seem to only work with
CRLF. We have a mixture of batch and shell scripts in our repository so
we would have to store them in with different line endings and hope
developers configure their editors on Windows to use LF for sh files and
CRLF for batch files and that users don't use their favorite text editor
that has its own idea about line endings. I think there is just too much
chance for something to go wrong here (it already happened to me and I
was being careful to avoid the problem)...
>>> One of the uses of this is to find out who last changed the file.
>>> Pardon me, but why does that matter?
>> You find a class that no longer behaves the way you expect it. So you
>> want to see who recently changed that class and review the recent commit
>> messages to see the most what the most likely culprit is. Is that such
>> an uncommon situation?
> You're making a logical jump that I wouldn't make, that the last person
> who changed the file is the last person who changed the class. I can
> only assume you're using Java, but that's not true in any other language
> I can think of.
Why? We use C++ but the implementation of each class is stored in one
file. So the person who last changed that file was the last to change
the implementation. Usually the commit message gives you an idea if it
could be related to the problem.
>> I guess if you know where(ie what line) the bug
>> was introduced then you could use annotate and this is often the case
> I would look at gannotate to see which lines are new. That also gives
> the commit log, and I can double-click for a diff.
I agree this is not a major problem and not a show stopper. gannotate is
More information about the bazaar