I'm in the process of converting a good-size (7 years, 6k files, 10k
commits) CVS repository to svn.
cvs2svn Statistics:
------------------
Total CVS Files: 5803
Total CVS Revisions: 24686
Total CVS Branches: 30046
Total CVS Tags: 559038
Total Unique Tags: 383
Total Unique Branches: 29
CVS Repos Size in KB: 350255
Total SVN Commits: 10513
First Revision Date: Mon Jun 12 15:09:38 2000
Last Revision Date: Thu Aug 16 11:24:12 2007
The catch is that this is commercial Mac OS code that has been
managed with MacCVS Pro <http://sourceforge.net/projects/maccvspro/>
so that files which have resource forks or MacOS metadata has been
stored with AppleSingle or MacBinary encoding.
The concensus of the discussion on the Subversion users list is that
this is not possible without either a client-side hook mechanism or a
patch to the Mac OS X svn client to make it understand the standard
file encodings.
Therefore I'd like to consult the svn developer community to see if
this can be done in a way the could be incorporated into a future
release of svn.
Along the way, it may also be able to handle a couple other issues
that have been discussed here, such as OpenOffice OOo files and Unix
ownership and permissions.
The user discussion is here:
<http://subversion.tigris.org/servlets/BrowseList?list=users&by=thread&from=611612>
I'll repeat the major points below....
The basic proposal, based on the discussion, is to allow:
1) Client-side encoding/decoding of files based on the MIME type
and/or other properties of files in the repository
2) Standard svn properties for platform-specific properties.
A general solution would be to have a client-side architecture where
handlers could be defined per MIME type to wrap files before check-in
and unwrap into local for on checkout.
This identical in concept to svn storing file names in UTF-8 and
converting to local conventions on checkout.
A simple implementation would be to just support the 4 standard Mac
OS file encodings in the Mac OS svn client as a test (and other
platforms in their respective clients). This does not preclude a more
general solution at a later date, but it does solve the problem of
Mac OS developers who cannot switch to svn because it cannot
represent their current repositories and may help a few developers on
other platforms.
From here, I'll concentrate on the Mac OS implementation, but the
general implications should be obvious:
There are 4 standard encodings for Mac OS files for platforms/file
systems that do not understand Mac OS file attributes, each with
assigned MIME types:
MacBinary application/macbinary
<http://en.wikipedia.org/wiki/MacBinary>
BinHex application/mac-binhex4 <http://en.wikipedia.org/wiki/Binhex>
AppleSingle application/applefile
<http://en.wikipedia.org/wiki/AppleSingle>
AppleDouble multipart/appledouble
<http://en.wikipedia.org/wiki/AppleDouble>
Based on a local settings file, MacCVS Pro allows files to be encoded
in any of the single file encodings (all but AppleDouble) in the
repository and automatically decoded on checkout to a normal file
with its resource fork and file attributes intact.
Given that, a repository converted from CVS/MacCVS Pro could be
handled by installing wrappers for:
application/macbinary
application/mac-binhex4
application/applefile
Additionally, Matt Slott has already developed a patch for
multipart/appledouble
<http://www.ambrosiasw.com/~fprefect/subversion-appledouble.html>
Although that could be subsumed into this one as well and implemented
as a wrapper: if a file has file:appledouble property, then the file
is AppleDouble encoded with the data file going to the repository and
the going to the repository and the header file going to the
file:appledouble property.
Other platforms will ignore the property and see only the data fork,
which is the desired behavior for AppleDouble. (Note that this can be
used to preserve Mac OS file type/creator even if there is no
resource fork)
NOTE: If you don't know the difference between a resource fork and an
AppleDouble header file (i.e. you think the ._ file MacOS X creates
on non-HFS volumes is a resource fork), please read the
AppleSingle/AppleDouble specification
<http://users.phg-online.de/tk/netatalk/doc/Apple/v1/> before
replying. ;-)
The same mechanism could be used to preserve unix- (or Windows-, or
whatever-)specific attributes, permissions, etc. (see
<http://subversion.tigris.org/tools_contrib.html#asvn>)
Feel free to shoot holes here, I'm looking for the simplest solution
that solves my problem, but in a way consistent with svn's purpose
that also lets me get my job done.
Since this is a general problem, the solution should be generally useful.
Thanks for your time.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 2 23:01:24 2007