Enforce always conflict during the update procedure?
From: Libor Jendele <Libor.Jendele_at_stredokluky.cz>
Date: 2005-07-07 11:17:46 CEST
I'm a novice to Subversion system. I just downloaded it and set it running. I have no problems; all seems to work fine (to my very limited experience). However, I found one thing that is (for me) difficult to accept: It is the automatic merging of server version and my private version of a document file during the process of updating. (This is my personal feeling. I respect that other people can see it different way...)
This situation will typically emerge, if both the server and my private (i.e. PC) version of a file gets modified. Upon my attempt to commit my version of the file to the server, (i.e. repository), I'll get an error message informing me about the conflict and suggesting me to update first (i.e. prior any commit) my local version of the file file from the server. That's fine; this is the way it should bahave.
Therefore I wonder, if you can suggest me. how can I suppress the quotted automatic merge during the update and enforce to obtain a conflict situation in all cases, i.e. even case of minor and negligable changes in the document during the update that are now handled automatically.
Another solution would be to allow such an automatic update but I'd get somewhere a copy of the version of the automatically updated files, (i.e. my local versions of the file) just prior the update.
Note that I have no problem with updates of my files form the repository that were not modified by myself. In that case I can always compare to an earlier version from the repository. That's fine.
Can I do it somehow from outside or a modification of the source code is needed? I tried to use external KDiff3 program with an option supressing any automatic merge. Unfortunatelly, it didn't help.
Can you help me or wher can I seek for help?
I'm using TortoiseSVN build-up to maintain the Subversion.
Note that I don't like to use locking and unlocking technique to protect the files, as I believe in open-source policy within developers' teams.
Thanks in advance for your help. Best regards
This is an archived mail posted to the Subversion Users mailing list.