??changed: -The first step is to mirror the CVS repository on your local host using the Savannah rsync access - you'll probably need to convert the repository a couple times before getting exactly what you want. The first step is to mirror the CVS repository on your local host using the Savannah rsync access - you'll probably need to convert the repository a couple times before getting exactly what you want::
??changed: -Note that if you work on Unix only, you're likely to only work with "text" files: CVS does _not_ set files as binary (cvs admin -kb) automatically (not by analysing content, _nor by extension_), unless extensions are mentioned in CVSROOT/cvswrappers or ./.cvswrappers, and that's only at import/add time, this has to be manually fixed later. For example, I had to run either of those to fix the Savane PNGs: Note that if you work on Unix only, you're likely to only work with "text" files: CVS does _not_ set files as binary (cvs admin -kb) automatically (not by analysing content, _nor by extension_), unless extensions are mentioned in CVSROOT/cvswrappers or ./.cvswrappers, and that's only at import/add time, this has to be manually fixed later. For example, I had to run either of those to fix the Savane PNGs:: ??changed: - ??changed: -'--use-cvs': use CVS instead of RCS, which is necessary in some rare cases; since we want a generic command line, let's use it, even if slower - -'--mime-types': adds a better content-type than application/octet-stream; not necessary strictly speaking - -'--fs-type=fsfs': the BDB (Berkley DB) format is apparently not a good one; FSFS is a bit more transparent and has some improvements. Savane uses it. --use-cvs: use CVS instead of RCS, which is necessary in some rare cases; since we want a generic command line, let's use it, even if slower --mime-types: adds a better content-type than application/octet-stream; not necessary strictly speaking --fs-type=fsfs: the BDB (Berkley DB) format is apparently not a good one; FSFS is a bit more transparent and has some improvements. Savane uses it. ??changed: -Importing in several steps may cause searches by date to provide bogus results, because SVN assumes that if revno1 < revno2, date_revno1 < date_revno2, which typically isn't necessary the case when importing different modules one after the other (with ever incrementing revnos). Here're the commands (not tested):: Importing in several steps may cause searches by date to provide bogus results, because SVN assumes that if revno1 < revno2, date_revno1 < date_revno2, which typically isn't necessary the case when importing different modules one after the other (with ever incrementing revnos). Here're the commands (not tested - uses svn2svn --dumpfile and svnadmin --parent-dir ... load):: ++added: You can reorganize the repository layout after the conversion, using svn mv. However, this makes it more difficult to search through the project's history later on, because the path will have changed and SVN doesn't follow renames automatically. ??changed: -Commands that I ran to convert Savane -(note: eventually the other Savane maintainer kept his own, less exhaustive, -conversion that he did a few days earlier):: Commands that I ran to convert Savane. Note: eventually the other Savane maintainer kept his own, less exhaustive, conversion that he did a few days earlier. As such I have no idea whether this multi-modules import would have caused history lookup errors as mentioned above:: -- forwarded from https://savannah.gnu.org/maintenance/[EMAIL PROTECTED]://savannah.gnu.org/maintenance _______________________________________________ Savannah-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/savannah-cvs
