(Resend, since the mail from my other account seems to have been
dropped)
In the latest cvs2svn.py, vendor branches are implemented by, for every
change in the vendor branch (i.e. import), copying the modified file to
the trunk (unless of course there has been a 1.2 commit to trunk before
that import). Any previous revision of the file in trunk is deleted
first. Here's an example:
Node-path: trunk/winedefault.reg
Node-action: delete
Node-path: trunk/winedefault.reg
Node-action: add
Node-copyfrom-rev: 231
Node-copyfrom-path: /branches/winehq/winedefault.reg
as a result of this
revision 1.1.1.2
date: 2000/11/23 15:07:47; author: andrewl; state: Exp; lines: +7 -2
Import of Nov 23 winehq.
on the vendor branch, when the default branch is assumed to be 1.1.1.
But this delete-and-recopy scheme is undesirable for me. Can it be made
so that instead of deleting the existing trunk copy and copying anew,
the existing trunk copy is updated with the text of the new vendor
branch revision instead?
"Why?", you may ask. Well, to preserve trunk's history in the case where
someone has been abusing cvs admin -b and then need to teach cvs2svn
when and where that happened.
For example, for this winedefault.reg, "someone" first committed a
change to it on trunk.
revision 1.2
date: 2001/04/28 01:15:07; author: ovek; state: Exp; lines: +98 -3
Registry entry that it seems Black&White needs
That patch was also submitted to the upstream authors ("WineHQ") and
merged there. The next release from WineHQ incorporated the patch, and
then cvs imported into the vendor branch:
revision 1.1.1.6
date: 2001/05/11 08:36:53; author: ovek; state: Exp; lines: +3 -0
Import of Wine release 20010510.
Now that there was no difference between 1.2 and 1.1.1.6, someone had
the bright idea of "tidying up" by using
cvs admin -b1.1.1 winedefault.reg
which sets the default branch back to 1.1.1, the vendor branch.
That's the first situation that called for changing cvs2svn. It assumes
there are no trunk commits when the default branch is 1.1.1, so I first
broke that assumption by changing
# Ratchet up the highest vendor head revision, if necessary.
if self.default_branch:
to
# HACK: Don't trust default branch, only let the absence of 1.2 matter
if self.default_branch and 0:
(As far as I can tell, the else case is perfectly sufficient for every
case I could think of, so I didn't need the if case and disabled it.)
Fair enough. But the problems don't stop there. What happens on the next
import, now that the default branch is 1.1.1?
revision 1.1.1.7
date: 2001/08/29 18:12:14; author: ovek; state: Exp; lines: +81 -0
Import of Wine release 20010824.
You guessed it. No manual merge to trunk. The 1.2 revision stays there,
but for casual cvs users, it doesn't matter, since they check out
1.1.1.7 since the default branch is 1.1.1.
I can't ask you to make cvs2svn detect this. It's next to impossible,
particularly since there *is* a later 1.3 version and the default branch
is thus no longer 1.1.1. I've had to put the problematic revisions into
a list, and then make is_trunk_vendor_revisions return 1 when it
happens, like so:
vendor_commits = {
'winedefault.reg': ['1.1.1.7','1.1.1.8','1.1.1.9'],
}
def is_trunk_vendor_commit(default_branches_db, cvs_path, cvs_rev):
vendor_commit = vendor_commits.has_key(cvs_path) and cvs_rev in vendor_commits[cvs_path]
if vendor_commit: return 1
if default_branches_db.has_key(cvs_path):
...
(and then a lot of crud in define_revision to alert me when I might have
a case like that on my hands, so I can investigate whether or not it is
and thus need to add that revision to the vendor_commits structure)
So far so good. But then it turns out that this aforementioned
delete-and-recopy scheme whenever is_trunk_vendor_commit returns 1 kills
the idea, by destroying the trunk file's history (in the example, its
revision 1.2 commit and associated log message).
Node-path: trunk/winedefault.reg
Node-action: delete
Node-path: trunk/winedefault.reg
Node-action: add
Node-copyfrom-rev: 1151
Node-copyfrom-path: /branches/winehq/winedefault.reg
So, whether you've read all the way here, or didn't bother with the
"why", how about a cvs2svn option to not delete-and-recopy in trunk, but
rather just change the trunk file's existing revision, preserving its
history?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 20 05:59:07 2004