Re: [PATCH] fix for issue 3404 (svnsync 1.6 fails on ^M)

Let me try to explain the thinking that lead to the current design of
my 3404 patch, and see if that helps answer your questions. In this
description I'll be distinguishing between SOURCE repositories and
TARGET repositories.

# why provide an option at all?

eol-style normalization *should* be a no-op when synchronizing SOURCE
repositories that don't require it. I'm just a little squeamish about
silently fixing up what I'm syncing without having been asked by the
user to do so.

# why store the option as a property of the TARGET repository?

Some SOURCE repositories require eol-normalization in order to be
successfully synced to a TARGET using svnsync 1.6. Other source
repositories do not.

Largely, this is a question of whether or not the source repository
has accepted commits from Subclipse on Windows in the past.

A source repository that requires eol-normalization *now* will
probably require it forever. We can't rely on the owner of the
source repository taking the time to do a dump->normalize->load.

A source repository that does not require eol-normalization *now*
probably won't require it in the future, as the defect in Subclipse
on Windows has been fixed.

From this I conclude:

  The answer to the question "does this SOURCE repository require
  eol-normalization in order to be successfully synced with svnsync
  1.6?" is a property of the SOURCE and is *unlikely* to change.

However:

  We have no way to associate this flag with the SOURCE, since it's
  outside of our control. The next logical place to store it is with
  the TARGET.

Therefore, I chose to provide this as an option to the init subcommand
so that the TARGET would remember this setting. This allows you, as
the creator of the TARGET repository to "set and forget" this.

# why store the option as a revprop in r0?

This seems to be where svnsync stores its metadata. Who am I to
question that?

# Problems with this design

In order to pass --fix-svn-prop-eol-style to init, you need to
*already* know that SOURCE requires it. The usual way to learn this
is by attempting first without --fix-svn-prop-eol-style and then
failing at some point during the initial sync. Possibly after hours
and thousands of revisions. Clearly, this is a bit of a
chicken-and-the-egg problem.

A user in this situation has three options:

1. start over by creating a new TARGET, passing
   --fix-svn-prop-eol-style this time.

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
   sync and copy-revprops.

I don't like the first option because it means repeating all the work
already done up to the point of the first failure.

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
repository to remember which of his clones require
fix-svn-prop-eol-style and which do not. This because a configuration
headache when one want to, e.g. sync a directory full of TARGET
repositories.

# What I'd really like

A subcommand to manipulate this flag, so that it can be set as
required after the first failure shows up. Alternatively,
--fix-svn-prop-eol-style on sync and copy-revprops could be made
"sticky", causing all future calls (even without the flag) to do
eol-style normalization.)

# The simplest design

The simplest design would just always do eol-style normalization, but
I'm hesitant about this.

Thoughts, suggestions, comments?

// ben

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2344718
Received on 2009-05-21 11:25:53 CEST