Martin v. Löwis schrieb: > Thomas Heller wrote: >> What I did was at a certain time develop in the 'branch_1_0' branch, leaving >> HEAD for experimental work. Later I decided that this was wrong, cvs >> removed all >> files in HEAD, and added them back from a branch_1_0 checkout. Maybe doing >> this was another bad idea, as the trunk in the converted SVN repository >> only lists _ctypes.c revisions corresponding to the CVS version numbers >> 1.307 up to the current CVS head 1.340. All the older versions from 1.1 up >> to >> 1.226.2.55 show up in the branch_1_0 branch that cvs2svn has created - >> although >> in CVS only the versions 1.226.0.2 up to 1.226.2.55 were ever in the >> branch_1_0 >> branch. Is that a bug in cvs2svnn? > > I doubt it. I'm pretty sure the subversion repository *does* contain all > the old files, in the old revisions. What happens if you do the > following on your converted subversion repository: > > 1. find out the oldest version of the files from svn log. Say this is > version 1000. > 2. Explicitly check out the trunk at version 950 (i.e. some plenty > revisions before your copied the files from the branch). > > I expect that this will give you the files just before you deleted > them; doing "svn log" on this sandbox will then give you all the old > log messages and versions. > > If that is what happens, here is why: "svn log" will trace a file > through all its revisions, and across "svn copy"s, back to when it > was added into the repository. At that point, "svn log" stops. > An earlier file with the same name which got removed is considered > as a different file, so "svn log" does not show its revisions. > > If you don't want that do happen, you could try to "outdate" (cvs -o) > the deletion and readdition in CVS, purging that piece of history. > I'm not entirely certain whether this should work.
You mean 'cvs admin -o', right? Yes, that works. Here is what I did: - got a local copy of the cvs repository from SF with rsync. All the following was done on thos local copy. - I ran 'cvs log' over the whole repository, and noted the files that were removed in the HEAD and later readded from a branch. - I wrote a script that calls 'cvs admin -o' on them. - removed those directories that should not be added to Python SVN, these were the ctypes-java, misc and CVSROOT directories. - called 'cvs2svn --dump-only' to create a subversion dumpfile. The file size is around 100 MB. - Created a local SVN repository, called 'svnadmin load'. Now I can checkout from the local SVN repository, and the whole history on the files that I checked is present. The svn checkup has this structure, which is OK imo: ctypes branches tags trunk The remaining questions are: - Do I need special rights to call 'svnadmin load' to import this dumpfile into Python SVN, or are the normal commit rights sufficient? What exactly is the URL/PATH where it should be imported (some sandbox, I assume)? - What about the Python trunk? Should changes from the sandbox be merged into Modules/_ctypes and Lib/ctypes, or would it be better (or possible at all) to use the external mechanism? Thanks, Thomas _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com