Tom Henricksen wrote:
> We are using Eclipse 3.1.2 and Subclipse 1.0.3 on Windows XP with
> Subversion 1.4. When we merge files I believe Subclipse creates files
> with extension like .mine, .r4538, and .r4540. Is there a way to turn
> this off? Also it adds decorators in the source file to designate
> what revision add what file. Something like the following:
>
>
>
>>>>>>> .mine
>
> if(variable != null) {
>
> <<<<< .r4382
>
> saveProfile(newProfile);
>
>
>
>
>
>
>
> Thanks in advance,
>
> Tom
>
>
>
>
>
Hi Tom,
I think your subclipse is working fine and does exactly, what it is
supposed to do:
* It saves your file in the state before the merge with ending .mine
* It saves the lower version (revision to be precise) merged in with
ending .[lower revision]
* the higher revision with the ending higher revision
* the decorators with the conflict in the file with the 'original'
ending
With this information you can check all versions involved in the merge
on its own and find the merge decision of Subversion.
If you want to go back to your original before the merge, just copy mine
to become the file with the 'original' ending. In some cases you may
prefer to copy in the file from the lower revision (e.g. to roll back
changes in the later version) or frequently the newer version.
In complex merges you may change by hand the conflicts in the file with
the 'original' ending
There is one well defined way in Subversion to get rid of the extra files:
svn resolved
After you have done one of the 3 copy actions or the manual conflict
resolution, this command will delete added files and mark the file with
the 'original' ending to be ready for the next merge or update,
depending what you tried to do. (Remember to remove the decorators and
check the code in the file with the original ending, subversion wouldn't
complain in the next commit, as it just checks for text differences)
I don't know any mechanism to turn of the creation of information and I
wonder if it would be a good idea to turn it off, because without those
files you would have to grab manually in the revisions of the
repository, the likelyhood to pick the wrong version and take wrong
decisions is quite high.
IMHO the presentation of the revisions involved in the merge is an
essential information for conflict resolution, the automated creation
creates the precise information.
Hope this helps
Markus
(If you need an example, check any subversion book, this mechanism is
well illustrated)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Thu Nov 16 21:56:23 2006