From: Markus Schiltknecht <markus@bluegap.ch>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: Jon Smirl <jonsmirl@gmail.com>,
Git Mailing List <git@vger.kernel.org>,
dev@cvs2svn.tigris.org, Shawn Pearce <spearce@spearce.org>
Subject: Re: Some tips for doing a CVS importer
Date: Mon, 27 Nov 2006 12:51:19 +0100 [thread overview]
Message-ID: <456AD137.8060209@bluegap.ch> (raw)
In-Reply-To: <456ACAF3.1050608@alum.mit.edu>
Hi,
Michael Haggerty wrote:
> I am currently the main (and pretty much the only) cvs2svn maintainer.
> Development has been proceeding more slowly lately because (1) I'm very
> busy with my day job, and (2) nobody has stepped forward to help.
I understand very well. Same for me here with monotone's cvs_import vs.
my day job... and then I also have a life ;-)
> Jon, I wish you wouldn't portray as obstinacy what is simply a lack of
> resources. I would like very much to support other cvs2svn output
> formats. I think it would be great if other projects could benefit from
> our work. Most of the work I've been doing on cvs2svn lately has been
> towards supporting other output SCMs.
Really? Hm. I'm somehow sorry for not joining cvs2svn but running my own
thing with monotone. But I really think it took me less time. OTOH, I'm
far from finished, yet...
Anyway, I've made an attempt at solving the 'picking better sources for
symbols'-problem:
During parsing of all the *,v files, where I'm collecting events
(commits, branching and tagging) into blobs, I do also remember
'possible parent branches' for all the symbols (tag and branch events).
After that and *before* the blob sorting, I check all blobs and try to
find one single parent branch for them. In the best case, those symbol
blobs do have exactly one possible parent branch, then I just pick that
one. If there are multiple possible parents, I try to pick the deepest.
As branches are symbols themselves, I have to run that multiple times
until all symbols are resolved.
An example: having branches ROOT -> A -> B -> C (branched in that order)
plus a branch D derived from branch A.
The symbol blob for branch A: has only one possible parent: ROOT. Thus I
assign A->parent_branch = ROOT.
Next comes the blob for branch C: it has two possible parents: branch B
and branch A. At that point we know that A is derived from ROOT, but we
don't have assigned a parent to B, yet. Thus we can not resolve C this time.
Then comes branch B: one parent: A. Mark it.
Next round, we process C again: this time, we know B is branched from A.
Thus we can remove the possible parent A. Leaving only one possible
parent branch: B.
Now, say we have a tag 'X', which ended up in a blob having A, B, C and
D as possible parent branches. I currently remove A and B, as they are
parents of C. But C and D still remain and conflict. I'm unable to
resolve that symbol. I'm thinking about leaving such conflicts to the
user to resolve.
I've not yet tested this algorithm extensively. Most larger repositories
seem to fail somewhere, but not necessarily because of that symbol
resolving algorithm... :-(
Any comments? Questions? Ideas? I hope to have explained clearly...
And I wish you all a lot of time for your open source projects and your
families, friends, wifes, girl-friends, etc...! ;-)
Regards
Markus
next prev parent reply other threads:[~2006-11-27 11:51 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-20 21:49 Some tips for doing a CVS importer Jon Smirl
2006-11-20 23:03 ` Martin Langhoff
2006-11-20 23:37 ` Jon Smirl
2006-11-21 0:29 ` Martin Langhoff
2006-11-21 0:55 ` Carl Worth
2006-11-21 1:40 ` Jon Smirl
2006-11-21 6:39 ` Shawn Pearce
2006-11-21 19:56 ` lamikr
2006-11-21 20:05 ` Shawn Pearce
2006-11-23 19:45 ` Robin Rosenberg
2006-11-25 6:59 ` Shawn Pearce
2006-11-21 20:03 ` Petr Baudis
2006-11-21 20:15 ` Shawn Pearce
2006-11-21 20:22 ` Johannes Schindelin
2006-11-23 9:10 ` Johannes Sixt
2006-11-21 20:40 ` Martin Langhoff
2006-11-21 1:53 ` Jon Smirl
2006-11-26 10:18 ` Marko Macek
2006-11-26 15:35 ` Jon Smirl
2006-11-26 16:11 ` Marko Macek
2006-11-26 17:51 ` Jon Smirl
2006-11-27 11:29 ` Michael Haggerty
2006-11-21 6:43 ` Shawn Pearce
2006-11-27 11:24 ` Michael Haggerty
2006-11-27 11:51 ` Markus Schiltknecht [this message]
2006-11-27 22:09 ` Michael Haggerty
2006-11-28 15:18 ` Markus Schiltknecht
2006-11-30 0:35 ` Michael Haggerty
2006-11-30 0:45 ` Daniel Jacobowitz
2006-11-27 15:20 ` Jon Smirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=456AD137.8060209@bluegap.ch \
--to=markus@bluegap.ch \
--cc=dev@cvs2svn.tigris.org \
--cc=git@vger.kernel.org \
--cc=jonsmirl@gmail.com \
--cc=mhagger@alum.mit.edu \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).