[Savannah-cvs] [CvSToSvN] (edit)

[Beuc]

??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/address@hidden://savannah.gnu.org/maintenance