From: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
To: Brian Downing <bdowning@lavos.net>
Cc: Gordon Heydon <gordon@heydon.com.au>, git@vger.kernel.org
Subject: Re: git cvsimport branches not consistent with CVS branches
Date: Sun, 8 Jul 2007 12:53:04 +0200 [thread overview]
Message-ID: <200707081253.06129.robin.rosenberg.lists@dewire.com> (raw)
In-Reply-To: <20070708054520.GD4087@lavos.net>
söndag 08 juli 2007 skrev Brian Downing:
> On Sun, Jul 08, 2007 at 10:45:10AM +1000, Gordon Heydon wrote:
> > After some investigation I found that git cvsimport was not importing
> > branches 100% correctly with CVS.
> >
> > Git and CVS do branching very differently in that CVS this is done at
> > the file level (like everything else) and git does it repository wide.
> >
> > So if I have a CVS repository with the files a, b and c and I branch b
> > with a `cvs tab -b BRANCH test` on the branch test I will just have the
> > file b.
> >
> > If I do a git cvsimport on the test branch there will actually be the
> > files a, b and c
> >
> > What I think needs to happen is that when git cvsimport created the
> > branch in the git repository it needs to delete all files from the
> > branch that were not branched.
>
> I've been vaguely working on Yet Another CVS Importer (an incremental
> one; both git-cvsimport (thanks to cvsps) and tailor take about ten
> minutes and a gigabyte of RAM to figure out that nothing has to happen
> with my repository. I think I can do better than that).
Corecode's fromcvs is pretty fast and incremental and AFAIK accurate. I had
plenty problems with cvsimport, but fromcvs keeps in sync with the CVS repo.
Get it at http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs/ .
It does not convert regular tags, only branches, however so there is something to
do for those that want a complete cvs import.
> In thinking about this case, I think I've decided that you want an
> option on what to do here. For some repositories you're not going to
> care about having extra files with the tag, and would greatly prefer
> that to having to create a branch for each and every tag (assuming you
> can arrange to have the correct files present otherwise; this isn't
> always possible.)
>
> For other cases, you really only want to get the subset of the files
> that are tagged. For this, I think the best arrangement would be to
> make your branch, then make a commit that only deletes the files that
> are not present in the CVS branch, as you said. Then immediately make
fromcvs drops the files that do not have the branch tag. It is pretty simple to change
the behaviour ( http://rosenberg.homelinux.net/gitweb/gitweb.cgi?p=FROMCVS.git;a=commitdiff;h=eb1c159bcc0d79eab182da3d7040ac62b52fd297 )
although this should be a switch and not hard coded.
-- robin
next prev parent reply other threads:[~2007-07-08 10:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-08 0:45 git cvsimport branches not consistent with CVS branches Gordon Heydon
2007-07-08 5:45 ` Brian Downing
2007-07-08 10:53 ` Robin Rosenberg [this message]
2007-07-08 11:47 ` Johannes Schindelin
2007-07-08 12:22 ` Robin Rosenberg
2007-07-08 21:02 ` Brian Downing
2007-07-08 14:38 ` Steffen Prohaska
2007-07-09 4:31 ` Josh Triplett
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=200707081253.06129.robin.rosenberg.lists@dewire.com \
--to=robin.rosenberg.lists@dewire.com \
--cc=bdowning@lavos.net \
--cc=git@vger.kernel.org \
--cc=gordon@heydon.com.au \
/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).