Hello, On Tue, Apr 27, 2010 at 2:58 PM, Tor Arntsen <tor@xxxxxxxxxxx> wrote: > On Tue, Apr 27, 2010 at 12:41, Marin Atanasov <dnaeon@xxxxxxxxx> wrote: > >> Perhaps I didn't explain better what I want to accomplish :) >> >> I want to convert CVS repo to a Git one. > > But the above statement.. > [..] >> What I want to do is to checkout from CVS the files which are tagged >> RELEASE_1_0 for example, and then import the files to a Git repo. >> Files tagged as RELEASE_1_0 differ from HEAD files, so I want only >> those files with that tag for example. > > .. seems to be in conflict with the above paragraph. Files tagged with > RELEASE_1_0 sounds like a revision tag (i.e. not a branch). If you > want to checkout that snapshot and insert into a Git rep you could as > well just 'cvs export -r RELEASE_1_0 <module>; git init; git add .; > git commit' > but that obviously won't give you any CVS history in the Git repo. > Yes, I could do that, but then I'll lose the history, which is the worst case. The import will be a one-time action. Once we import everything from CVS to Git, we don't use CVS anymore, so no need of incremental imports. > Is RELEASE_1_0 instead a branch tag? I.e. a CVS branch? RELEASE_1_0 is just a CVS tag you create using `cvs tag <tag-name> <file>`. The CVS repo does not contain any branches at all. We have a lot of test and production systems, where production systems fetch from a central repository the files tagged as STABLE, and test systems fetch the files tagged as TEST. Another workaround that I'm thinking of might be: 1. git-cvsimport the whole CVS repository. 2. create a new bare repo, and fetch the files previously imported by git-cvsimport to master branch - that way we'll have all the history we need in the master branch. 3. checkout from CVS files tagged as STABLE, TEST, etc... to a new repo, and then add, commit them to a git repo. 4. fetch again the repo in point 3. to the bare repo from point 2., in the specified branch -> TEST, STABLE, etc.. 5. I won't have the history in the STABLE, TEST, etc.. branches, but I'll have it in the master branch then. 6. From later on we'll be using after all the TEST, STABLE, etc. branches, so master will be kept untouched. 7. On the central repository we'll just clone the already created bare repo that contains the master, TEST, STABLE, etc.. branches, and we'll set it to track TEST, STABLE, etc. for example. What do you think about this? Is it a good approach at all? Regards, Marin > > -Tor > -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html