ignore ancestry and record only

[chroyer <ch...@comcast.net>]

Hi all, 

I was wondering if the following scenario makes sense, or if this is asking for problems. 

* I am regularly merging differences between 2 trees (I won't go in too much details here...those tree are not really under my control; I put those them in the tags area, and I want to merge the changes between 2 consecutive such snapshots. In my case, I can not just use a branch and update it with the latest version - the tree gets modifications before being tagged). 

* to merge the differences between 2 snapshots, I am using --ignore-ancestry (otherwise I see a lot of files being "replaced"). This works great 

* since --ignore-ancestry makes me loose the merge info, before I commit the merge results, I merge again but this time with --record-only (and without --ignore-ancestry) 

* now I can commit and it seems that I have the best of both worlds... 

I think this is more an svn question (but I am using I am using tsvn 1.6.16). The server is svn 1.6.17 
Does anyone have experience with similar scenario? 

Thank you, 
Christophe 

Re: ignore ancestry and record only

[chroyer <ch...@comcast.net>]

> > 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 

Re: ignore ancestry and record only

[Stefan Sperling <st...@elego.de>]

On Tue, Oct 02, 2012 at 09:35:19AM +0200, Ulrich Eckhardt wrote:
> Am 01.10.2012 21:07, schrieb chroyer:
> >I was wondering if the following scenario makes sense, or if this is
> >asking for problems.
> >
> >   *  I am regularly merging differences between 2 trees (I won't go in
> >too much details here...those tree are not really under my control; I
> >put those them in the tags area, and I want to merge the changes between
> >2 consecutive such snapshots. In my case, I can not just use a branch
> >and update it with the latest version - the tree gets modifications
> >before being tagged).
> 
> It's unfortunate that you don't want to go into details here.

Indeed. In addition to explaining your intentions and problem, which
you've done very well, please show us the commands you're using to
implement your approach. Having to guess what you're actually doing
makes giving advice over email harder. 

> >   *  to merge the differences between 2 snapshots, I am using
> >--ignore-ancestry (otherwise I see a lot of files being "replaced").

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".
It may well be that a simple tweak to your command sequence could 
fix problems with replacements and the like.

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.

Re: ignore ancestry and record only

[Ulrich Eckhardt <ul...@dominolaser.com>]

Am 01.10.2012 21:07, schrieb chroyer:
> I was wondering if the following scenario makes sense, or if this is
> asking for problems.
>
>    *  I am regularly merging differences between 2 trees (I won't go in
> too much details here...those tree are not really under my control; I
> put those them in the tags area, and I want to merge the changes between
> 2 consecutive such snapshots. In my case, I can not just use a branch
> and update it with the latest version - the tree gets modifications
> before being tagged).

It's unfortunate that you don't want to go into details here. It sounds 
like a typical "vendor branch" (search the SVN book!). Here, we are 
using several external libraries. When upstreams releases a new version 
(snapshot), we load it into the repository (using svn_load_dirs) and 
then apply some local modifications (like integration into our own build 
system but also bugfixes). When a new version comes in, we do the same, 
merging the changes from the older version if appropriate.


>    *  to merge the differences between 2 snapshots, I am using
> --ignore-ancestry (otherwise I see a lot of files being "replaced").

This might be due to the way that you load the new version.


>    * since --ignore-ancestry makes me loose the merge info, before I
> commit the merge results, I merge again but this time with --record-only
> (and without --ignore-ancestry)
>
>    * now I can commit and it seems that I have the best of both worlds...
[...]
> Does anyone have experience with similar scenario?

I really think that what you are doing is equivalent to maintaining a 
vendor branch. Check the docs, they have examples for this use case, 
and/or provide a bit more info if you still have questions.

Good luck!

Uli


**************************************************************************************
Domino Laser GmbH, Fangdieckstra�e 75a, 22547 Hamburg, Deutschland
Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Domino Laser GmbH ist f�r diese Folgen nicht verantwortlich.
**************************************************************************************