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

Lock merge function into working copy

From: Bernard TREMBLAY <bty-adminf1_at_trebly.net>
Date: Sat, 19 Feb 2011 08:30:32 -0800 (PST)

Hi,

Into the FAQ we can find the subject :
prevent Subversion from doing automatic merges?

Some people don't like the fact that Subversion merges changes from others with their own local working copy changes automatically on update. Here's how to force those files into a conflicted state so you can merge manually at your convenience.

   1. In TortoiseSVN->Settings->Subversion configuration file, click on the edit button.
   2. Change the [helpers] section by adding diff-cmd = "C:\\false.bat" diff3-cmd = "C:\\false.bat" (note the double backslash)
   3. Create the file C:\false.bat which contains two lines

      @type %9
      @exit 1
                                  

This effectively makes auto-merge fail every time, forcing the file into conflict.

The reason for the curious 'type %9' line is that the diff3-cmd sends the merged output to stdout. Subversion then takes this and overwrites your local file with the merge results. Adding this line avoids getting an empty local file.

This is very usefull because when you use templates (smarty) and css any merge can generate a lot of work to make a manual merge and generally you have lost your original file.

Then the lonely way to work is to lock the merge on the local worked copy and get the new updated into a <filename-with-.extension>.<new version>.<file extension> to make comparisons and solve manually conflict.

Why such a name for the update file (new version not merged) ?
1- If we use the file name with extension into the dir the update file will be below
2- the extension is added because if not the external editor will not be able to hightlight and syntax analyse.

In another way there is a locking problem is that the expression :
"[helpers]" section is an auto referenced expression reserved to initiated persons :
I mean :
search on the whole site on the word "helpers" neither in docs don't give any result : it is something hidden.

So it is a dead lock.

A rule "never use words or expressions" in any DOC or FAQ which don't gives as result the lonely text you have just redacted : this creates a "closed semantic space" for users.

I y resume :

1- Where do we find an [helpers] section
2- How the update locked (not applied) is named
3- How this update locked file could have the pattern that I use.

For the moment I need before an SVN update I need :
1- to run a batch where I have referenced the files that must not not be merged : this batch copies the file with a versioning pattern

2- Delete the main files

3- Update and for each "new" file create a versioned copy. and delete the original one

4- Copy the first (mine) to the file name

5- Make a comparison for each one (sometime 50 files)
and validate or not, upgrade and/or let in conflict state.

During this time there is no chance to make any significant test or other work on the product which can't function.

For the moment I have 67 files in such conflict, 12 declared conflicts on the 7484 files (TPL,PHP,CSS,JS)

Most of time TPL (smarty) and CSS can't be merged automatically (near 70%).

This takes half time of development.

the need is
1- to quickly build a list of files not merged and merged ones and make comparisons (For most of merged files they are out of my work so I have nothing to do).

2- to keep named (renamed) conflicted versions

Sorry if I have been long. But for the moment, I develop nothing because my development are concerning crossed parts of projects.

Thanks for your answer

Trebly
B10219-04

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2705554

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-02-19 17:30:45 CET

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

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