> On Fri, 8 Feb 2002 01:14:05 -0500 (EST)
> Daniel Berlin <dan@dberlin.org> wrote:
>
> > > Please don't do that. We don't want to leave conflict markers in files
> > > because someone always screws up conflict resolution
>
> ...
>
> > I have a hard time believing this.
> > So i grepped gcc's cvs repo, and it appears to have only ever happened
> > once outside of the changelogs (where it happens every 200 revisions or
> > so).
>
> I seem to remember running into conflict markers in files multiple times
> when working in devo. Also, files that get compiled would tend to generate
> syntax errors so this will come up less in C code that it does general files.
> The fact that merge conflicts show up in the ChangeLog should be a
> blinking red warning sign with a loud horn.
>
> I was under the impression that one of subversion's design goals was
> to avoid mucking up the users files. Sure everyone could be more careful,
> but the tool could help by not getting users into error prone situations
> in the first place.
>
> Mo
>
Personally, I find the conflict markers very convenient and find applying
patches that don't apply cleanly by hand to be a real pain. However, I know
plenty of people who are confused by those markers, probably because the
working copy part is labelled horribly. If these markers are to be
generated, I would suggest making them look like
<<<<<<<<<<<<< 1.17
new version in repository
======
local version
>>>>>>>>>>>>> local version
CVS uses the file name instead of "local version" which confuses everyone
since it leaves one wondering which version of that file.
Anyway, I think this just screams to be configurable, especially since
merging is already slated to be a configurable item anyway. Merging should
definitely be configurable (for reasons that have probably already been
mentioned but are repeated here anyway) at least so that non-text files can
use a merging utility that understands the types of files being merged. I
would suggest producing the base revision (I believe this is already stored
in the working directory base files), the new version in the repository, and
the local file (already available) and passing all three of these to a shell
script. The shell script could then decide what to do with these; diff then
patch, use 3-way merge program, make conflict markers, make .rej files,
whatever. The conflict gets noted in the working copy metadata (somewhere
in the .svn directory probably as a property). Another shell script could
be used to check whether conflicts have been resolved by default by the
pre-commit hook script. This shell script would need to take a file name
and check if the conflicts have been resolved for that file. The default
wold be to abort the commit if the conflicts haven't been resolved. If the
script determined the conflict had been resolved, it would clear the
conflict flag.
I don't think svn should be set up to always reject files that have
conflicts as this is a policy decision (at least in my mind). I can see
uses for checking in files that still have conflicts on branches so that
someone else can easily grab them and fix the conflicts (perhaps someone
with more knowledge about the part of the system with the conflict).
Anyway, just my 2 cents. In the end, it probably doesn't matter too much.
Thanks for thinking all these things through, this kind of carefulness is
what is going to end up making svn great IMO.
- Scott Lenser
---------------------------------------------------------------------
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