Re: [PATCH] fix for issue 3404 (svnsync 1.6 fails on ^M)
From: B. Smith-Mannschott <bsmith.occs_at_gmail.com>
Date: Thu, 21 May 2009 11:25:31 +0200
Let me try to explain the thinking that lead to the current design of
# why provide an option at all?
eol-style normalization *should* be a no-op when synchronizing SOURCE
# why store the option as a property of the TARGET repository?
Some SOURCE repositories require eol-normalization in order to be
Largely, this is a question of whether or not the source repository
A source repository that requires eol-normalization *now* will
A source repository that does not require eol-normalization *now*
From this I conclude:
The answer to the question "does this SOURCE repository require
We have no way to associate this flag with the SOURCE, since it's
Therefore, I chose to provide this as an option to the init subcommand
# why store the option as a revprop in r0?
This seems to be where svnsync stores its metadata. Who am I to
# Problems with this design
In order to pass --fix-svn-prop-eol-style to init, you need to
A user in this situation has three options:
1. start over by creating a new TARGET, passing
2. manually set svn:sync-fix-svn-prop-eol-style on r0
3. remember to always pass --fix-svn-prop-eol-style to future calls to
I don't like the first option because it means repeating all the work
I don't like option two because it feels like a hack.
I don't like option three because it requires the owner of the TARGET
# What I'd really like
A subcommand to manipulate this flag, so that it can be set as
# The simplest design
The simplest design would just always do eol-style normalization, but
Thoughts, suggestions, comments?
This is an archived mail posted to the Subversion Dev mailing list.