I'm not sure if this list or python-dev is appropriate for the more general dvcs discussions - apologies if I got it wrong. There is one issue I'm yet to see addressed - Windows line endings.
When the svn tree is checked out on windows, all text files have \r\n line endings. While many dev tools are capable of working with \n line endings, this quickly becomes inconvenient - eg, my "patch" tool will always insert \r\n line endings, simple commnd-line redirections and dumb editors also will result in mixed or swapped line endings. If we move to a VCS without this support, it becomes trickier to compare, eg, an old svn tree with a new tree on windows as every file differs. While commit hooks etc can go some way to preventing such files from being checked in, it would be much better to avoid the problem in the first place by using native windows line endings, as done by svn.
So I guess the first question is: how much importance do we want to put on that capability?
To the best of my knowledge, bzr's support for this is a few months away. I keep hearing rumours mercurial does support it and I'm just starting work on a mercurial based project, so I may be able to find some answers there - does anyone else have experience with mercurial and windows line endings? I've never used git but again, heard rumours there is some support.
Thoughts?
Mark
On Wed, Feb 25, 2009 at 6:14 PM, Mark Hammond <mhammond@skippinet.com.au> wrote:
To the best of my knowledge, bzr's support for this is a few months away. I keep hearing rumours mercurial does support it and I'm just starting work on a mercurial based project, so I may be able to find some answers there - does anyone else have experience with mercurial and windows line endings? I've never used git but again, heard rumours there is some support.
I can't add much more, but there's a section for this in the PEP: http://www.python.org/dev/peps/pep-0374/#crlf-lf-support
-- Regards, Benjamin
Le mercredi 25 février 2009 à 18:24 -0600, Benjamin Peterson a écrit :
On Wed, Feb 25, 2009 at 6:14 PM, Mark Hammond <mhammond@skippinet.com.au> wrote:
To the best of my knowledge, bzr's support for this is a few months away. I keep hearing rumours mercurial does support it and I'm just starting work on a mercurial based project, so I may be able to find some answers there - does anyone else have experience with mercurial and windows line endings? I've never used git but again, heard rumours there is some support.
I can't add much more, but there's a section for this in the PEP: http://www.python.org/dev/peps/pep-0374/#crlf-lf-support
And it is even covered in the "minimal setup" section: http://www.python.org/dev/peps/pep-0374/#hg
And it is even covered in the "minimal setup" section: http://www.python.org/dev/peps/pep-0374/#hg
I can't make the mercurial instructions work; I'm yet to investigate why though.
But my wider point was that there doesn't seem to be a required level of functionality, or even a blanket statement along the lines of "native eol support must offer as much functionality as svn". eg, what would, and would not, be considered a "deal-breaker" in this area? Anything?
Cheers,
Mark
On Wed, Feb 25, 2009 at 21:11, Mark Hammond <mhammond@skippinet.com.au>wrote:
And it is even covered in the "minimal setup" section: http://www.python.org/dev/peps/pep-0374/#hg
I can't make the mercurial instructions work; I'm yet to investigate why though.
But my wider point was that there doesn't seem to be a required level of functionality, or even a blanket statement along the lines of "native eol support must offer as much functionality as svn". eg, what would, and would not, be considered a "deal-breaker" in this area? Anything?
If windows users get screwed that's a deal breaker. I have not looked at the line endings section of the PEP yet, though, to know if they are at the moment.
-Brett
Brett Cannon wrote:
On Wed, Feb 25, 2009 at 21:11, Mark Hammond <mhammond@skippinet.com.au <mailto:mhammond@skippinet.com.au>> wrote: But my wider point was that there doesn't seem to be a required level of functionality, or even a blanket statement along the lines of "native eol support must offer as much functionality as svn". eg, what would, and would not, be considered a "deal-breaker" in this area? Anything?
If windows users get screwed that's a deal breaker. I have not looked at the line endings section of the PEP yet, though, to know if they are at the moment.
That sounds like a "not worse than SVN" to me (which means allowing it to be set on a per-file basis, but also being able to set it up so that checked in text files were marked that way by default).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Le jeudi 26 février 2009 à 16:11 +1100, Mark Hammond a écrit :
And it is even covered in the "minimal setup" section: http://www.python.org/dev/peps/pep-0374/#hg
I can't make the mercurial instructions work; I'm yet to investigate why though.
There's some doc here: http://www.selenic.com/mercurial/wiki/index.cgi/Win32TextExtension If you want to be sure the extension has been enabled, you can try "hg showconfig".
If you still have problems with it, you could post on the mercurial ML: http://selenic.com/mailman/listinfo/mercurial or through the gmane bridge: http://news.gmane.org/gmane.comp.version-control.mercurial.general/
And it is even covered in the "minimal setup" section: http://www.python.org/dev/peps/pep-0374/#hg
I think this setup is incomplete: you should also add encode/decode sections to list all file name patterns that should see line conversion. Not sure when to use cleverencode and when to use dumbencode, though.
Regards, Martin
Thoughts?
Procedurally, I think there are many open issues. I'm not sure whether they get collected somewhere - so far, I took the position that I'll wait for a final proposal of a specific technology, with a specific demo setup, and then look what is wrong with this setup.
Among the issues that have not been adequately addressed so far are:
- conversion of the complete history
- performance of the tools
- availability of Windows support equivalent to TortoiseSVN
- pre-commit checks
- post-commit actions (such as commit emails, buildbot triggers)
I think this specific issue (text mode and line endings) definitely belongs into the list of issues that need to be resolved, and I think it should be show-stopper if it isn't adequately resolved (i.e. it needs to be at least as good as CVS and subversion).
Regards, Martin
participants (7)
-
"Martin v. Löwis" -
Antoine Pitrou -
Benjamin Peterson -
Brett Cannon -
Jim Fulton -
Mark Hammond -
Nick Coghlan