Bug#58743: cvs: problem resurrecting files on trunk
tags 58743 = confirmed upstream wontfix
thanks
I’ve looked at this in great detail now again.
The structure of file,v at the time of merge is as follows:
RCS file: /home/tg/cvsrepo/cvsbug/Attic/file,v
Working file: file
head: 1.2
branch:
locks: strict
access list:
symbolic names:
branch_tag: 1.1.0.2
keyword substitution: kv
total revisions: 4; selected revisions: 4
description:
----------------------------
revision 1.2
date: 2016-10-21 16:45:31 +0000; author: tg; state: dead; lines: +0 -0; commitid: 100580A464542AA74BA;
Removed file from trunk.
----------------------------
revision 1.1
date: 2016-10-21 16:44:43 +0000; author: tg; state: Exp; commitid: 100580A46150B1F1096;
branches: 1.1.2;
Added file on trunk.
----------------------------
revision 1.1.2.2
date: 2016-10-21 16:45:16 +0000; author: tg; state: Exp; lines: +2 -0; commitid: 100580A463649CE67C1;
Added file on branch.
----------------------------
revision 1.1.2.1
date: 2016-10-21 16:44:43 +0000; author: tg; state: dead; lines: +0 -1; commitid: 100580A463649CE67C1;
file file was added on branch branch_tag on 2016-10-21 16:45:16 +0000
=============================================================================
The problem here is that the merge instructs CVS to merge the
delta from 1.1 to 1.1.2.2 into HEAD, not the delta from the
not-recorded common ancestor -r0.
This is due to the way CVS treats file additions vs. branches;
it simply does, at the time of the merge, not *know* that the
common ancestor of the branches is -r0 not -r1.1.
On the other hand, we *could* possibly use the knowledge that
the first branch revision is dead (1.1.2.1) to force the addition.
This would cause mayhem later on, though: committing that records
only -r1.2 as parent of -r1.3, not -r1.1.2.2, so the next join
with only one -j parameter would try to add the file again.
Your best bet is probably to always tag a branch base… the
automatic :BASE revisions don’t work as branch_tag:BASE also
resolves to 1.1 though.
I don’t think I’m involved deeply enough with CVS’ internals
to make a judgment call here; if you still need this (things
indicate you don’t) please contact upstream.
If you indeed tag your working copy at the time of branching,
i.e. before 'cvs tag -b branch_tag' run 'cvs tag bbase', the
merger 'cvs up -jbbase -jbranch_tag' *does* add the file.
I think this is all I can do to help, sorry.
bye,
//mirabilos
--
13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs
13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you
13:28⎜«neurodamage:#cvs» you're a handy guy to have around for systems stuff ☺
16:06⎜<Draget:#cvs> Thank god I found you =) 20:03│«bioe007:#cvs» mira2k: ty
17:14⎜<ldiain:#cvs> Thanks big help you are :-) <bioe007> mira|nwt: ty again
18:35⎜«alturiak:#cvs» mirabilos: aw, nice. thanks :o
18:36⎜«ThunderChicken:#cvs» mirabilos FTW! 23:03⎜«mithraic:#cvs» aaah. thanks
18:41⎜«alturiak:#cvs» phew. thanks a bunch, guys. you just made my weekend :-)
18:10⎜«sumit:#cvs» mirabilos: oh ok.. thanks for that
21:57⎜<bhuey:#cvs> yeah, I really appreciate help
18:50⎜«grndlvl:#cvs» thankyou 18:50⎜«grndlvl:#cvs» worked perfectly
20:50⎜<paolo:#cvs> i see. mirabilos, thnks for your support
00:36⎜«halirutan:#cvs» ok, the obvious way:-) thx
18:44⎜«arcfide:#cvs» mirabilos, I am running OpenBSD. 18:59⎜«arcfide:#cvs»
Hrm, yes, I see what you mean. 19:01⎜«arcfide:#cvs» Yeah, thanks for the help.
21:33⎜«CardinalFang:#cvs» Ugh. Okay. Sorry for the dumb question. Thank you
21:34⎜<centosian:#cvs> mirabilos: whoa that's sweet
21:52⎜«garrett__:#cvs» much appreciated «garrett__:#cvs» thanks for your time
23:39⎜<symons:#cvs> this worked, thank you very much 16:26⎜<schweizer:#cvs> ok
thx, i'll try that 20:00⎜«stableable:#cvs» Thank you. 20:50⎜«s833:#cvs»
mirabilos: thanks a lot. 19:34⎜<bobbytek:#cvs> Thanks for confirming :)
20:08⎜<tsolox:#cvs> ...works like a charm.. thanks mirabilos
Reply to: