-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 08 February 2002 06:59 am, cmpilato@collab.net wrote:
> > > cp working_file working_file.00000.12345.rej
> > > apply diff3 contextual diffs to the rej-file
> > > if diffs apply cleanly
> > > rm working_file; mv rej-file working_file
> > > else
> > > list rej-file in the entries file and mark working_file as
> > > conflicted
...
> edit out the conflict markers in working_file.00000.12345.rej
> rm working_file
> mv working_file.00000.12345.rej working_file
I'm going on record as saying that I dislike both the old and the current
method, and your suggestion looks good... except that it is rather involved,
don't you think? I mean, there are too many steps. I can forsee having to
refer back to a howto document every time I want to resolve a conflict, as
rarely as they occur. At the very least, I'm actually going to have to
*think* about *how* to apply the resolution, when all I should have to think
about is resolving the conflict. This is going to generate the same sorts of
complaints that people (such as myself) have about the "<<<<<>>>>>" syntax: I
just can never remember what the proper sequence is. I also forsee an initial
slew of "how do I resolve conflicts in SVN", followed quickly by a FAQ entry,
end then endless "Read the FAQ" answers.
I'm of the opinion that if something is done nearly the same way every time,
a computer should be doing as much of it as possible, not a person. Can your
algorithm for /the process/ of resolving conflicts (not the conflict
resolution itself, of course) be automated in any way?
- --
|.. "Discovery consists in seeing what everyone else has seen and
<|> thinking what no one else has thought."
/|\ -- Albert Szent-Gyorgi
/|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8Y/ZTP0KxygnleI8RAhD3AJ90WhDANO05IaSkVOfi5TDWT7CjdwCeO+fo
C0A2ASf/lRwfnPSszEJk15E=
=hQI7
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:05 2006