> > It's unfortunate that you don't want to go into details here. Sorry, I did not want to muddy the water...but let me try. The items I am tracking originate from a different version control system in which we implemented an artificial way to branch (using batch files). That tree will be used for a little longer, but we are transitioning to svn. We have a trunk in svn, and a branch (like a vendor branch in that case) to import the old tree. When we did not have "patches" in the old tree, it was simply a matter of updating the branch then merge it into the trunk (not a reintegrate; the branch is never getting changes from the trunk).
Branching in the old tree is implemented by running specific batch files to copy files around, thus creating a new tree. Those batch files can only be applied to an unpatched tree. So, to keep as much history as possible, I get the old tree in the svn branch, get a WC where I run the appropriate patch batch file, then tag from that working copy. The next time the old tree is updated, I repeat the process. Now I have 2 tags, and I can diff them to port those changes in my trunk (well, I use an intermediate branch, the trunk will get those changes when things get more stable). What I like is that I can easily go back and see that the "merge" was done properly (without having to get the old tree at a specific rev and apply to proper patch - it's all in the svn tags area) > Please show us all svn commands you're running, starting from "putting > snapshots into the tags area" up to "I see a lot files being > replaced". I am using tsvn to perform all the steps I need. Getting the old tree is done like getting a vendor branch (I don't use the perl script though). Tagging the WCis also no issue. The only "unusual" for me is when I merge the diff between 2 tags; I use "merge 2 different trees" and tsvn log gives me something like: Merging from <old tag> , revision HEAD to <new tag>, revision HEAD into <working copy>, ignoring ancestry then Merging from <old tag> , revision HEAD to <new tag>, revision HEAD into <working copy> then I commit > It's usually best to provide a list of commands (a working shell > script > is even better) that starts off with an empty repository and ends with > the command where you're running into a problem. This way, others can > try to reproduce the problem and figure out a solution. I really appreciate your help, and I know this list can provide very thorough support. I am not running into any issue yet, and I was not really anticipating going into many details; rather I was wondering if at a high level that approach of first merging with --ignore-ancestry then merging again with --record-only (then commit) was raising any red flag. While it seems to work now, I can't tell if this will be an issue later (hence asking if someone had similar experience). Thank you all Christophe
