Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: error (nike.apache.org: local policy)
Date: Sun, 25 Aug 2013 15:44:05 -0700
From: Travis Brown <travisb@travisbrown.ca>
To: Les Mikesell <lesmikesell@gmail.com>,
        Ryan Schmidt <subversion-2012c@ryandesign.com>,
        Branko ??ibej <brane@wandisco.com>,
        Subversion <users@subversion.apache.org>, dev@subversion.apache.org,
        John Maher <JohnM@rotair.com>
Subject: Re: Switching
Message-ID: <20130825224405.GA24769@daredevil.travisbrown.ca>
Mail-Followup-To: Les Mikesell <lesmikesell@gmail.com>,
	Ryan Schmidt <subversion-2012c@ryandesign.com>,
	Branko ??ibej <brane@wandisco.com>,
	Subversion <users@subversion.apache.org>, dev@subversion.apache.org,
	John Maher <JohnM@rotair.com>
References: <5217A562.3020202@gmx.us>
 <54C87FD8-9CBD-41A3-9D6B-F7C1C787BB60@ryandesign.com>
 <5218656B.6020302@wandisco.com>
 <9DEB2347-7103-49A2-AC8C-51C8223C3069@ryandesign.com>
 <CAOAgVpzO2+YG1=5fe4Atc-28jLs8eRDtVEyrjcuuhYtOJJjPFA@mail.gmail.com>
 <20130824190447.GB8910@ted.stsp.name>
 <20130824192641.GA5617@daredevil.travisbrown.ca>
 <20130824195313.GC8910@ted.stsp.name>
 <20130824215749.GA7559@daredevil.travisbrown.ca>
 <20130825094611.GE8910@ted.stsp.name>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=x-unknown;
	protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ"
Content-Disposition: inline
In-Reply-To: <20130825094611.GE8910@ted.stsp.name>
User-Agent: Mutt/1.4.2.3i


--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 25, 2013 at 11:46:11AM +0200, Stefan Sperling claimed:
>Looking at just one use case is not going to help us in the long term.
>And I don't think we should hard-code conflict resolution behaviour in
>the update/switch/merge logic.
>
>During 1.8 development, I did experiment with hard-coded conflict
>resolution choices on several occasions (see, for example,
>http://svn.apache.org/r1161219). Those changes got shot down during
>peer review, because there were cases where the hard-coded behaviour
>was problematic. More importantly, intertwining conflict resolution
>with the update/merge logic tends to make the code overly complicated
>and fragile once we look past trivial conflict cases.
>
>So our current approach is to always flag conflicts during update and
>merge, and then let 'svn resolve' deal with these conflicts in a
>separate step. I would consider your patch if it made 'svn resolve'
>deal with the tree conflict raised on the obstructing directory,
>rather than changing how 'svn switch' behaves now.
>
>We've spent a lot of time on detecting tree conflicts, and in 1.8 we've
>also started to improve the interactive menu for tree conflicts involving
>local moves. I'd like to see further improvements there, even if it's
>harder than patching up a few use cases. I think we'll get a more
>flexible and reliable system in the long term this way.

It's nice to finally see a concrete, technical objection.

I took a brief look at the resolution code and found it to be a twisty
maze of callbacks and workqueues. There didn't appear to be any existing
infrastructure or obvious way to resolve the tree conflict on the
directory and then continue with whatever operation caused the conflict
in the first place. This isn't my itch so I'm uninterested in spending
any more time than I have already investigating it. IMHO any solution to
this problem which requires any further user input, whether a manual
conflict resolution or running a second command, is a waste of time.
What I saw in my brief look indicates that it'll be a significant effort
to accomplish this level of polish with the existing code structure.

Since my patch has legitimate objections and I'm not willing to
implement the supported alternative I'll let this drop now.

--=20
Travis

--rwEMma7ioTxnRzrJ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iF4EAREKAAYFAlIaiLUACgkQG8QSN8unuFr71gEA7EuUSjF86u2CgVk2rMIKiwNf
enJ0Xnhccakk3+K9uGsBAJEr1hZFaaQ4HYguFjKHITLe+YlgiVLwQAtYkfvIKudj
=ZbEu
-----END PGP SIGNATURE-----

--rwEMma7ioTxnRzrJ--