> > 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 , revision HEAD to , revision HEAD into
, ignoring ancestry
then
Merging from , revision HEAD to , revision HEAD into
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
