Bazaar as Subversion replacement

[Nicholas Allen]

>> Is this not high on the priority list? Is it really so hard to
>> implement?
>>     
>
> 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
> everywhere.
>
>   
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 
very useful!