[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Never merge?

From: Bob Archer <bob.archer_at_amsi.com>
Date: Fri, 25 Sep 2009 09:36:28 -0400

> > But surely you still need to handle the conflict by regenerating the
> file?
> > Since that takes a lot of time or effort, why bother that you first
> have to
> > mark the conflict as resolved?
> The problem is that this is XML that has generated values that I as a
> user am depending on.
> I have no clue about the data in this XML so I expect the best for me
> to be having my own version as
> the correct one in a conflict. Marking the file as resolved: does it
> lead me to having my own file as
> the right one and that no conflict is there? Doesn't resolve on a
> conflicting file lead to the file
> being with mine-info in the file?

It depends on how your resolve the conflict. You could resolve with theirs or mine or use a 3way merge tool. svn only does what you tell it to do when it detects a conflict.

> Allowing the user to edit this xml will make the user not have accurate
> info in his file.
> In this case the user wants to have the latest version but if he/she
> forgot to update, they should
> handle their own file as the correct one (never merge).
> But I think the best way would be to mark this file as a binary file,
> that case it will not be merged right?

Is this a file you don't want people committing if they modify it locally. If so it sounds like maybe this file should be in source control as a .template that the user would have to copy to the correct file name. They can edit their local version as needed and if they see that the .template file is updated they can compare the two files and update their local file as needed.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-25 15:38:22 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.