Bazaar as Subversion replacement

[Nicholas Allen]

> Well, that's pretty useful feedback, so thankyou.  Is the situation in
> svn just perfect for your situation or is there anything else we should
> take into account?
>   
For our needs svn has served us very well and we have basically had no 
problems with it. That's not to say there isn't room for improvement but 
at least the approach used by svn seems to be a reasonable one. We do a 
lot of development an both Windows and Mac OSX and I cannot remember the 
last time we had a line ending issue.

We have a precommit check on the server to make sure the user has 
specified a line ending style for any files that have a mime type of 
text/* (the mime type of a file is stored as a property on that file - 
svn:mime-type). The user can configure subversion client to 
automatically set properties on files when they are added by a file name 
pattern. By default subversion identifies all files as binary (and sets 
the mime type to application/octet-stream) if they don't match any of 
the patterns the user provided.

It would be nice if similar constraints could be specified in bzr so 
that you can say "if this property is set to a value matching <regex> 
then make some other property is set to <regex> before allowing commit". 
This allows you to setup a convention so that if I try to commit a file 
with text/* mime type without specifying line ending convention bzr 
would display an error message. This would need to work without network 
access as bzr is distributed. So these constraints would need to be 
stored in the bzr branch itself and would need to be versioned. This 
would not be an executable file (as this is hard to make cross platform 
and opens up security issues) but some config file that is flexible 
enough to specify constraints between various properties that get set on 
files.

I think svn's approach could also be improved upon by bzr in 2 ways:

    1 Instead of just having a global file that matches file name 
patterns to default properties to set on that file, bzr could have a 
global config as well as an optional per-branch config that is stored in 
the repository. Bzr would try the branch config first and then the 
global config. If a file does not match any pattern then it is binary.

    2 Bzr could warn the user when they add a file and a pattern 
identifies it as text/* mime-type but it appears to contain binary 
characters (this is unlikely to happen but will prevent data corruption 
in the case that a file is somehow identified as text but is actually 
binary). Bzr could even refuse to set the mime type to text/* if this is 
the case for complete peace of mind. Of course it is still possible that 
a file is binary but does not contain any binary chars AND has a file 
name that would identify it as text. In this case it is possible to 
corrupt the data. This is such a rare problem I think that it is not 
worth worrying about - for all intents and purposes it just won't happen.
> Lineending conversion is divisive: some people have got into trouble
> using it, but to others it's necessary.
> The basic approach of svn, in our terms, is that a filter is interposed
> between the on-disk files when they're read or written.  This would not
> be so hard to add.
>
>   
That's what I would have thought. I didn't really understand why this 
would need a new repository format as Aaron suggested. I would have 
thought this conversion could happen without the repository being aware 
of it. Aaron: a new format only be needed to support the versioned 
properties?
> It's a high priority for me to land this for the next release.  There
> should be a patch for review, including the documentation, some time
> soon.
>   
Great! Look forward to trying it out soon ;-)