You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Steve Sisak <sg...@codewell.com> on 2007/10/02 21:00:37 UTC
Pre/Post-processing files on check-in/out
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
Re: Preserving MacOS Files in SVN (was: Pre/Post-processing)
Posted by Steve Sisak <sg...@codewell.com>.
At 9:14 PM -0400 10/3/07, Mark Phippard wrote:
>This is all interesting. Perhaps we need to reopen this discussion
>(beyond just resource forks). Here's the deal though. We are closing
>in on the 1.5 branch date so people are really trying to focus on
>getting the final loose ends wrapped up so we can get the done.
No problem -- I certainly understand the situation.
I think I've proven to myself that some update to svn is needed to
accomplish what I need to convert over, and have a release to get out
myself, so I'm probably going to try and limp through on CVS for one
more release while we get this sorted out and will be glad to
participate as needed in the future.
(A friend has reminded me off-list of NTFS and UDF also having
multi-fork features and rsync's xattr support as a related example
which should be considered in a general solution)
>I'd suggest you start this thread over again after the release is done
>when people are in a frame of mind where we are defining the next
>release.
Will do.
>If you think that patch you mentioned is the right approach, perhaps
>some people can work together to get it updated for current /trunk,
>cleaned up, some documentation, tests will be important etc.
I'll check w/Matt and some others -- even if it's not "the" right
approach, it feels like it's part of the right approach or at least a
good interim approach, in that files encoded this way do retain all
their data and could easily be converted to another encoding later.
The only issue I see is the one Brian Fitzpatrick brought up about
storing more than 64k in a property being a performance issue.
If the penalty isn't severe, and assuming we can just re-encode such
files in the future, once support for AppleSingle (or equivalent more
general solution) is available, this may be good enough to remove or
significantly reduce the entry barrier for Mac users and developers.
>Anyway, just wanted to let you know that for the sake of getting the
>release done a lot of us need to drop out of this discussion for a
>while and I did not want you to think you are being blown off.
No problem -- I'll let you guys get back to work for now and take a
look at Matt's patch as an interim solution.
Best wishes,
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Preserving MacOS Files in SVN (was: Pre/Post-processing)
Posted by Mark Phippard <ma...@gmail.com>.
On 10/3/07, Steve Sisak <sg...@codewell.com> wrote:
> >Basically, you are talking about the format of the file stored in
> >Subversion repository and the format of the file in the WC not being
> >the same. Given that, how would you solve the following?
>
> Can I have an acronym expansion on WC? (Assuming Working Cache)
WC == Working copy.
[lots snipped]
This is all interesting. Perhaps we need to reopen this discussion
(beyond just resource forks). Here's the deal though. We are closing
in on the 1.5 branch date so people are really trying to focus on
getting the final loose ends wrapped up so we can get the done.
I'd suggest you start this thread over again after the release is done
when people are in a frame of mind where we are defining the next
release. You are likely to pull in more of the debate that is needed
to really move this forward if people are more prepared to engage you.
I think right now a lot of people see this and see that there is no
way we are going to tackle this for 1.5 and just hit delete. We will
ultimately need some of those people to read this and get on board.
If you think that patch you mentioned is the right approach, perhaps
some people can work together to get it updated for current /trunk,
cleaned up, some documentation, tests will be important etc.
Anyway, just wanted to let you know that for the sake of getting the
release done a lot of us need to drop out of this discussion for a
while and I did not want you to think you are being blown off.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Preserving MacOS Files in SVN (was: Pre/Post-processing)
Posted by Steve Sisak <sg...@codewell.com>.
At 5:57 PM -0700 10/3/07, Jack Repenning wrote:
>The issue here is that both the server and the client have
>information about "the file." If you burst the AppleSingle/Double
>into an actual bundle or double-fork,
Woa -- I think I see what you're missing here. There's no bundle or
"double fork" there's only ONE FILE on the Mac.
The whole double fork thing is faked so that it's possible to access
parts of the file other than the data fork using POSIX APIs -- if
you're using the native Mac OS API there's only one file and if
you're on a native file system, there's only one object on disk.
You open the data fork with FSpOpenDF()
You open the resource fork with FSpOpenResFile()
You can open the resource fork of a file as a flat file with FSpOpenRF()
(I'm listing older APIs for clarity -- the new FSRef APIs support an
arbitrary number of forks per file and opening any fork as data or
resources)
>then the objects on disk at the client end (in the working copy or
>"WC") will be different, in number, content, name, and timestamp,
>from "the file" as perceived by the server.
There's only one file on disk and one file on the repository -- the
issue we're trying to solve is that svn only saves part of it (the
contents of the data fork) in the repository and discards the rest.
A bundle is a directory in the file system with a bit set in one of
the extended attributes (that isn't preserved by svn either) to
indicate that it should be presented to the user as if it were a
single file -- but on disk it's a directory tree.
>There's also a sort of a cache of this kind of info, in the .svn/
>directory: metadata in the "entries" file, a pristine copy of "the
>file" in the text-base/*.svn-base file, and so on. A complete
>implementation will have to do something or other about those.
I'll need to do some more research on that.
>For example, in all current cases, Subversion decides whether there
>has been a change in part by comparing the time stamp recorded in
>"entries" against the time stamp of "the file" on disk.
That's OK, because once "the file" has been decoded (or more
properly, reassembled), there's still only _one_ _file_ on disk --
it's now the whole file with all its parts.
>But if the server storage is, say, AppleDouble, then the most
>obvious implementation would make the .svn/ stuff AppleDouble, but
>the file on disk would be data + resource forks. When comparing
>time stamps, we would compare the time stamp in "entries" for the
>single AppleDouble file against the time stamp of which fork?
The file. There's only one file on disk. Only one time stamp.
Mac files have multiple forks.
The obvious implementation to me would be to make pristine copy in
text-base/*.svn-base a Macintosh file, with all its parts recombined,
rather than just the data fork of the original file.
>Would really have to be both, I think, since either can change independently.
There's only one timestamp because there's only one file once it's
been reassembled.
>If de-AppleDoubling the resource fork (or, whichever piece is done
>first) takes longer than a second, or takes a nanosecond but slops
>over a second boundary, then the file and resource forks have
>different time stamps, don't they?
There's only one file. :-)
>If we just accept that the timestamp comparisons are impractical,
>then we'll have to actually compare the files (not sure, but I think
>it's actually done by comparing MD5 sums, currently). This will
>require reconstituting the AppleDouble from its scattered parts.
I don't think this is an issue because, once the file is
reconstituted on Mac OS, there's only one file.
The difference between AppleDouble and AppleSingle only affects how
it's stored in the repository.
If it's stored as AppleDouble, then other platforms see the data fork
of the Mac file as a file (of whatever MIME type) that they can edit,
with a property containing the Mac-specific bits that are re-attached
if it's checked out on a Mac. (This would affect the modification
time of the file when reconstituted)
If it's stored as AppleSingle, other platforms see a binary file of
type application/applefile, which they probably aren't going to do
much with.
>This would be a big performance hit, and it comes up a lot (it's the
>basis of "svn status" and the icon badging done by GUIs, not merely
>checkin/update).
Probably not an issue if you reconstitute the file whenever it's on
the local file system -- it's only encoded when it's in the
repository.
Does this make sense?
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Preserving MacOS Files in SVN (was: Pre/Post-processing)
Posted by Jack Repenning <jr...@collab.net>.
On Oct 3, 2007, at 5:20 PM, Steve Sisak wrote:
>> * client uses a heuristic to determine if file is changed
>> locally. In
>> this case, to check if a file is modified it would have to be
>> encoded,
>> and then if the size is not different, a byte by byte compare would
>> have to be performed.
>
> What's wrong with modification time? Mac OS modification time is
> only updated if a file (any part) is changed.
>
> In any case, this is no different that having 2 files plus a small
> fixed size header. How does the client currently handle a 1 byte
> write to the middle of a file (which wouldn't change the length)?
The issue here is that both the server and the client have
information about "the file." If you burst the AppleSingle/Double
into an actual bundle or double-fork, then the objects on disk at the
client end (in the working copy or "WC") will be different, in
number, content, name, and timestamp, from "the file" as perceived by
the server.
There's also a sort of a cache of this kind of info, in the .svn/
directory: metadata in the "entries" file, a pristine copy of "the
file" in the text-base/*.svn-base file, and so on. A complete
implementation will have to do something or other about those. For
example, in all current cases, Subversion decides whether there has
been a change in part by comparing the time stamp recorded in
"entries" against the time stamp of "the file" on disk. But if the
server storage is, say, AppleDouble, then the most obvious
implementation would make the .svn/ stuff AppleDouble, but the file
on disk would be data + resource forks. When comparing time stamps,
we would compare the time stamp in "entries" for the single
AppleDouble file against the time stamp of which fork? Would really
have to be both, I think, since either can change independently.
If de-AppleDoubling the resource fork (or, whichever piece is done
first) takes longer than a second, or takes a nanosecond but slops
over a second boundary, then the file and resource forks have
different time stamps, don't they?
If we just accept that the timestamp comparisons are impractical,
then we'll have to actually compare the files (not sure, but I think
it's actually done by comparing MD5 sums, currently). This will
require reconstituting the AppleDouble from its scattered parts.
This would be a big performance hit, and it comes up a lot (it's the
basis of "svn status" and the icon badging done by GUIs, not merely
checkin/update).
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Preserving MacOS Files in SVN (was: Pre/Post-processing)
Posted by Steve Sisak <sg...@codewell.com>.
At 11:08 AM -0400 10/3/07, Mark Phippard wrote:
> > There, done. Any holes?
>
>I probably should not wade into this discussion as it seems like
>asking any questions gets interpreted as not wanting to see the
>feature added.
Hopefully that's not the case -- if you can identify technical
issues, that would be a good thing.
>I use OSX (not these features in general) and would
>like to see it better supported so that there are no barriers to
>adoption.
Thanks.
>That being said, I do not see where any of the proposed solutions
>really talks about how Subversion actually works and how it would need
>to be modified.
I'm only beginning to dig into that, so your help would be most appreciated.
>Basically, you are talking about the format of the file stored in
>Subversion repository and the format of the file in the WC not being
>the same. Given that, how would you solve the following?
Can I have an acronym expansion on WC? (Assuming Working Cache)
>* client and server communicate with binary deltas. This means that
>the client will have to convert local file to repository
>representation to exchange deltas. Say there are local changes to a
>file, and you are updating from server. The local version has to be
>encoded, receive and apply the deltas, and then be decoded again. Can
>this be done reliably? How would/could conflicts be handled?
The encodings in discussion are just a concatenation of the various
streams (with headers) -- as long as we use the same order of the
segments, the encoding can be done on the fly easily.
>* client uses a heuristic to determine if file is changed locally. In
>this case, to check if a file is modified it would have to be encoded,
>and then if the size is not different, a byte by byte compare would
>have to be performed.
What's wrong with modification time? Mac OS modification time is only
updated if a file (any part) is changed.
In any case, this is no different that having 2 files plus a small
fixed size header. How does the client currently handle a 1 byte
write to the middle of a file (which wouldn't change the length)?
>This will be very slow. Let's assume it is
>worth it, is the process reliable? Does encoding/decoding the same
>file always give the exact same results?
Please take a moment to examine the definition of the AppleSingle and
AppleDouble formats:
<http://en.wikipedia.org/wiki/AppleSingle>
<http://users.phg-online.de/tk/netatalk/doc/Apple/v1/>
I think this will answer your question.
Since there are file system calls to open the resource fork as a flat
file, both formats are essentially the concatenation of a header and
one or two files -- the header contains the extended file attributes
and offsets and sizes of the other two files in the "encoded" file.
The difference is wether the data fork is included or a stand-alone file.
>I am sure the important parts of a file are always exactly the same
>but is the actual binary encoded file always exactly the same?
Since the order of resources in the resource fork is inconsequential,
modifying a resource in the middle of a file might reorder the
contents of the resource fork section of the file, but I believe that
this would always be the result of an actual change.
>If not, you are going to get a lot of false positives from svn
>status, which means those changes will be committed.
If this were to be deemed a serious issue, there's no reason we
couldn't sort the resource fork on the first status call after a
modification.
>* an alternative to previous, is that perhaps the decoded version of
>the file is stored in the WC to make these comparisons faster.
Assuming the WC is the local cache, that would be fine, as we're
really just talking about local files.
>But then SVN needs to be enhanced to compare resource forks too.
You can open the resource fork as a file and use normal file compare
-- you just won't see the structure or catch a false positive where a
resource has moved in the file but not changed.
However if the flat comparisons are equal, the resource forks are identical.
>It also
>pushes the complications back to the process that talks to the server
>as now an extra encoding step has to happen.
Will need to look at the code -- if you have an abstraction of a file
stream, is could be generated on the fly.
>Are all of these problems solvable? Most likely ... there are a lot
>of smart people around. I do not think the solution is nearly as easy
>as it is being portrayed.
We do have an existing implementation of AppleDouble submitted as a
patch, although I have not dived into too deeply yet.
>I do not think there is any reason to respond to this email point by
>point.
Oops. Too late. :-)
>I am not a core SVN coder, I will not be making these changes.
> I think you should just take these things into consideration in the
>proposal and try to address them so we can keep the proposal moving
>forward. Or perhaps step back and think of a different approach that
>makes these things less of an issue.
No problem.
Thanks for the review.
What I'm hoping is that the "encoded" file can be represented as a
stream that just a concatenation of the (manufactured) header, the
resource fork (read as a byte stream), and the data fork (for
AppleSingle).
This might generate a false positive for a change if a resource is
modified and changed back, but that's no worse than a source file
being reordered, but at least all the data in the file is preserved.
A smarter resource fork compare would be a good thing, but that would
be another case of a smarter XML compare for XML-based files
(structured files where order is not significant) -- I'd consider it
an optimization.
Best wishes,
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Preserving MacOS Files in SVN (was: Pre/Post-processing)
Posted by Mark Phippard <ma...@gmail.com>.
> There, done. Any holes?
I probably should not wade into this discussion as it seems like
asking any questions gets interpreted as not wanting to see the
feature added. I use OSX (not these features in general) and would
like to see it better supported so that there are no barriers to
adoption.
That being said, I do not see where any of the proposed solutions
really talks about how Subversion actually works and how it would need
to be modified.
Basically, you are talking about the format of the file stored in
Subversion repository and the format of the file in the WC not being
the same. Given that, how would you solve the following?
* client and server communicate with binary deltas. This means that
the client will have to convert local file to repository
representation to exchange deltas. Say there are local changes to a
file, and you are updating from server. The local version has to be
encoded, receive and apply the deltas, and then be decoded again. Can
this be done reliably? How would/could conflicts be handled?
* client uses a heuristic to determine if file is changed locally. In
this case, to check if a file is modified it would have to be encoded,
and then if the size is not different, a byte by byte compare would
have to be performed. This will be very slow. Let's assume it is
worth it, is the process reliable? Does encoding/decoding the same
file always give the exact same results? I am sure the important
parts of a file are always exactly the same but is the actual binary
encoded file always exactly the same? If not, you are going to get a
lot of false positives from svn status, which means those changes will
be committed.
* an alternative to previous, is that perhaps the decoded version of
the file is stored in the WC to make these comparisons faster. But
then SVN needs to be enhanced to compare resource forks too. It also
pushes the complications back to the process that talks to the server
as now an extra encoding step has to happen.
Are all of these problems solvable? Most likely ... there are a lot
of smart people around. I do not think the solution is nearly as easy
as it is being portrayed.
I do not think there is any reason to respond to this email point by
point. I am not a core SVN coder, I will not be making these changes.
I think you should just take these things into consideration in the
proposal and try to address them so we can keep the proposal moving
forward. Or perhaps step back and think of a different approach that
makes these things less of an issue.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Preserving MacOS Files in SVN (was: Pre/Post-processing)
Posted by Steve Sisak <sg...@codewell.com>.
At 5:00 PM +0200 10/3/07, Brian W. Fitzpatrick wrote:
>Storing more than 64kb in a Subversion property is going to cause
>performance problems.
That's useful information -- basically it means that we want to
include AppleSingle support for files which have lots of resource
data.
This matches usage pretty well:
Files that have a data fork that is of use on other platforms (the
reason for using AppleDouble) tend to have very little or no resource
data. Therefore this limit is unlikely to be hit.
Files that have a lot of resource data, tend to be essentially binary
and are of no interest on other platforms, therefore AppleSingle
encoding is appropriate and this limit will not be relevant.
Files that have no resource data have a very small AppleDouble header
file (just the extended file attributes, etc.)
>Having arbitrary properties run client side scripts is a security hole
>big enough to drive a truck through.
OK -- we can avoid this by simply implementing the encodings in the
Mac OS svn client for now.
>Why can't you just use Rez ad DeRez again? You don't "lose" old
>versions unless you totally nuke your CVS repository.
Efficiency: in files that have a lot of resource data, that data tend
to be binary (graphics, icons, sounds, etc.) -- storing them as an
ASCII hexadecimal dump is rather inefficient.
Effort: This requires a lot of manual effort, plus modifications to
the build procedures for every project.
Also, this still doesn't address the non-resource Mac OS file
attributes that are lost (file type, creator, finder comments,
creation date, etc.)
>Just how many Mac developers out there have this "critical need" and
>how does the above described feature help non Mac-developers?
Anyone with existing code.
In the Mac programmers lists I frequent, not being able to to store
mac files (and not providing as an escape) has left svn as a nice toy
to try on a new project when I don't have to preserve existing code.
In the user front, svn doesn't handle Mac file types or other
standard attributes, bundles, etc. -- most Mac file attributes are
lost.
There are plenty of existing file formats that use resources, for
instance most graphics packages create custom thumbnail icons for
images which are stored as resources in a JPEG file.
>My main concern here is that this seems like an awful lot of code
>churn for a feature that is needed for a feature (resource forks) that
>Apple has deprecated and that affects a microscopic number of people.
Deprecated and not currently in use are two different concepts.
Further you have to realize that there are multiple political camps
at Apple -- notably the Mac OS / NeXT split. The nexties have been
trying to deprecate the Carbon API in favor of Cocoa for years, but
most major commercial applications (including the Mac OS Finder and
iTunes) are Carbon -- as is Photoshop, Microsoft Office, etc.
(A friend at Apple once suggested to best way to model Apple is a
self-contained venture capital firm with 100 little start-ups all
fighting for funding)
As far a the number of developers, by not providing proper support
for the existing Mac OS file system in svn, you have self-selected
the Mac developer community out of the subversion community.
Most that I know have evaluated svn and either stuck with CVS or
moved on to Perforce.
Now with Perforce jacking up their licensing fees and imposing
ridiculous policies, there are a bunch examining svn again to see if
it's ready for prime time.
I've been wanting to use it myself for several years (and have been
using it on a smaller project with a subset of my source tree for 9
months), but its inability to hold my existing source base without
significant modification to hundreds of files has been a barrier.
>I understand that this is an inconvenience, but I'm always hesitant to
>add a feature for something that 1) affects very few people and 2) has
>a workaround (ie Rez and DeRez).
At the moment, it affects a lot more people than you realize (they
have gone on to other products or deferred adoption until they can
start a fresh project with no legacy code) and there is no practical
workaround (you are still focusing on resource forks rather than
losslessly representing Mac OS files).
Subversion is extremely close to being a useable product, but this is
a deal breaker for most commercial developers because we can't import
our existing code and be sure that we haven't lost data.
Neither can users store an arbitrary file and be sure that it is all
there on checkout.
HTH,
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Preserving MacOS Files in SVN (was: Pre/Post-processing)
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On 10/3/07, Steve Sisak <sg...@codewell.com> wrote:
> Given that these are file system encodings, it's
> probably reasonable to implement them directly in
> the svn client and defer discussion of a general
> MIME type handling architecture for a 2nd pass --
> nothing precludes pulling the code out into a
> wrapper at a later time once an architecture has
> been designed.
>
> Note that, while I've define everything needed
> for Mac OS (because there's a critical need),
> there's nothing here that's platform-specific in
> that all that is needed is to provide a platform
> property equivalent equivalent to
> file:appledouble an define its contents. This
> just happens to have already fully defined for
> Mac OS for over a decade.
>
> There, done. Any holes?
Comments:
Storing more than 64kb in a Subversion property is going to cause
performance problems.
Having arbitrary properties run client side scripts is a security hole
big enough to drive a truck through.
Questions:
Why can't you just use Rez ad DeRez again? You don't "lose" old
versions unless you totally nuke your CVS repository.
Just how many Mac developers out there have this "critical need" and
how does the above described feature help non Mac-developers?
And lastly:
My main concern here is that this seems like an awful lot of code
churn for a feature that is needed for a feature (resource forks) that
Apple has deprecated and that affects a microscopic number of people.
I understand that this is an inconvenience, but I'm always hesitant to
add a feature for something that 1) affects very few people and 2) has
a workaround (ie Rez and DeRez).
-Fitz
PS Interesting tar wrappers fun:
http://svn.haxx.se/dev/archive-2003-02/1485.shtml
PPS Total disclosure: I used to work at Apple
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Preserving MacOS Files in SVN (was: Pre/Post-processing)
Posted by Jack Repenning <jr...@collab.net>.
On Oct 3, 2007, at 12:02 PM, Steve Sisak wrote:
> At 10:39 AM -0700 10/3/07, Jack Repenning wrote:
>> On Oct 3, 2007, at 7:30 AM, Steve Sisak wrote:
>>> It might also be useful to have a way to exclude certain resource
>>> types as there are some instances where resources are used to
>>> tack "additional" information onto "normal" files that need not
>>> be saved. For instance, most Mac text editors use a 'CKID' to
>>> indicate a file's version control status (modifiable, read-only,
>>> modified read-only) and use the 'MPSR' resource to save the
>>> current text selection, etc. across edits.
>>
>> This sounds like it might be stepping a bit beyond the basic
>> requirement?
>
> Take this as "sometimes there are resources that are truly
> disposable and need not be preserved".
Right, that was how I took it. I was hesitating over the
implementation effort for configurability, extension to newly-
discovered cases, differences of opinion over the disposability of
various resources, etc.
-==-
Jack Repenning
jackrepenning@tigris.org
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"
Re: Preserving MacOS Files in SVN (was: Pre/Post-processing)
Posted by Steve Sisak <sg...@codewell.com>.
At 10:39 AM -0700 10/3/07, Jack Repenning wrote:
>On Oct 3, 2007, at 7:30 AM, Steve Sisak wrote:
>>It might also be useful to have a way to exclude certain resource
>>types as there are some instances where resources are used to tack
>>"additional" information onto "normal" files that need not be
>>saved. For instance, most Mac text editors use a 'CKID' to indicate
>>a file's version control status (modifiable, read-only, modified
>>read-only) and use the 'MPSR' resource to save the current text
>>selection, etc. across edits.
>
>This sounds like it might be stepping a bit beyond the basic requirement?
Take this as "sometimes there are resources that are truly disposable
and need not be preserved".
(Although having a list of resource types not to preserve in a
preference is a common idiom -- or a way to say "don't bother saving
the resource fork of this file")
Sorry if I complicated things with too much detail -- should probably
set this aside to avoid a tangent anyway.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Preserving MacOS Files in SVN (was: Pre/Post-processing)
Posted by Jack Repenning <jr...@collab.net>.
On Oct 3, 2007, at 7:30 AM, Steve Sisak wrote:
> It might also be useful to have a way to exclude certain resource
> types as there are some instances where resources are used to tack
> "additional" information onto "normal" files that need not be
> saved. For instance, most Mac text editors use a 'CKID' to indicate
> a file's version control status (modifiable, read-only, modified
> read-only) and use the 'MPSR' resource to save the current text
> selection, etc. across edits.
This sounds like it might be stepping a bit beyond the basic
requirement?
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Preserving MacOS Files in SVN (was: Pre/Post-processing)
Posted by Steve Sisak <sg...@codewell.com>.
At 7:50 PM -0700 10/2/07, Jack Repenning wrote:
>On Oct 2, 2007, at 6:55 PM, Steve Sisak wrote:
>>Passé or not, I still need to support Mac OS
>>resource forks, types and creators (those are
>>on their way back) and other Mac OS file
>>metadata.
>
>Yeah, I was afraid of that. Had to ask, you know.
>
>>But if you cast the problem as "support for
>>general MIME type decoding", that has general
>>usefulness. Supporting Mac OS files attributes
>>is just a test case.
>
>Hey, I like that "requirements judo"! I agree
>it puts the key parts of the change into
>somewhere useful to all platforms (I'm real
>paranoid about non-Mac developers breaking our
>Mac-o-syncracies - nothing personal, just an
>abiding sense of fragility).
Cool. Assuming that we're agreed that we're
working on a part of a general solution, let's
scope it way down to something that can be
implemented.
I have 1 requirement: That storing and retrieving
a file in svn be a lossless operation.
(A pretty basic requirement for a version control system, don't you think)
In the case of Mac OS, this means that I get back
the whole file -- data fork, resources, type,
creator, script code, creation date, etc.
This applies to other platforms as well. If a
version control system can't preserve the
(entire) contents of a file over a check-in and
check-out on the same platform, then it doesn't
have much standing to call itself cross-platform,
right? :-)
That said, if we scope the requirement slightly
to "lossless when checking in and out on the same
platform", this gets a lot easier to solve.
The idea is that, for files that are accessed by
more than one platform, the platform-specific
attributes are saved in a property that follows
the file around and ignored by platforms that
don't understand the additional information.
(It's my understanding that this is an intended
use of svn properties)
For files that are truly platform-specific, we
also have the option to simply encode them as
binary files and use the MIME type to indicate
how they are encoded. Platforms that don't
understand that encoding see them as binary files.
>>The MIME types for Mac OS file encodings have
>>been set in stone for at least a decade (maybe
>>2).
>>
>>Matt has proposed file:appledouble for the
>>property which contains the AppleDouble header
>>file (associate with a given data file) -- the
>>format of the contents has been defined since
>>A/UX. Unless there are major objections from
>>someone, it's fine with me.
>
>Why isn't the standard name for this property
>"svn:mime-type"? I think there are official
>standard MIME types for AppleDouble and -Single
>(multipart/appledouble and
>application/applefile, respectively), so
>anything with that MIME type could, by a Mac
>client, be exploded into the "real" file on
>checkout, and glommed back up on checkin, right?
>
>(Mental note about non-Macophilic file systems,
>like UFS, on Mac platforms....)
Getting back to this, let's focus on 2 encodings:
AppleSingle and AppleDouble as these are:
1) Both the same format and can share code
2) What Mac OS X uses to represent Mac files on non-Macophilic file systems
Both contain the entire file and all its extended
attributes in a well-defined (and extensible)
format -- the only difference it that AppleSingle
encodes everything in a single (binary) file and
AppleDouble leaves the data fork in a traditional
flat file (accessible by any platform) and puts
the Mac-specific bits a separate flat file
(called the header file, a.k.a. the ._ file).
(MacBinary and BinHex are older encodings
semantically equivalent to AppleSingle -- these
could either be supported directly or converted
to AppleSingle when importing the repository)
Matt's proposal for supporting AppleDouble in svn
is simply to check in the data file and attach
the header file as a file:appledouble property. A
patch is already available:
<http://www.ambrosiasw.com/~fprefect/subversion-appledouble.html>
AppleSingle can be implemented by encoding the
file on check-in and setting the svn:mime-type
property to "application/applefile" (or
equivalent for application/macbinary and
application/mac-binhex4).
The choice of wether to use AppleSingle or
AppleDouble is left to the user, depending on
wether the file is essentially binary or is a
"normal" file with some extra data attached.
A good 1st approximation is that, if the file has
a resource fork, AppleSingle should be used --
otherwise AppleDouble should be used.
It might also be useful to have a way to exclude
certain resource types as there are some
instances where resources are used to tack
"additional" information onto "normal" files that
need not be saved. For instance, most Mac text
editors use a 'CKID' to indicate a file's version
control status (modifiable, read-only, modified
read-only) and use the 'MPSR' resource to save
the current text selection, etc. across edits.
Once in the repository, if the file's
svn:mime-type is application/applefile it is
AppleSingle encoded on check-in, otherwise, if it
has a file:appledouble property (regardless of
MIME type), then it is AppleDouble encoded and
the property updated if any of the metadata has
changed.
Given that these are file system encodings, it's
probably reasonable to implement them directly in
the svn client and defer discussion of a general
MIME type handling architecture for a 2nd pass --
nothing precludes pulling the code out into a
wrapper at a later time once an architecture has
been designed.
Note that, while I've define everything needed
for Mac OS (because there's a critical need),
there's nothing here that's platform-specific in
that all that is needed is to provide a platform
property equivalent equivalent to
file:appledouble an define its contents. This
just happens to have already fully defined for
Mac OS for over a decade.
There, done. Any holes?
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Pre/Post-processing files on check-in/out
Posted by Steve Sisak <sg...@codewell.com>.
At 11:29 PM -0400 10/2/07, Augie Fackler wrote:
>QuickTime components rely fairly heavily on resource fork components
>and the way we handle this is by storing our resource fork elements
>in a rez file which then gets hit with Rez as part of the build
>system - maybe you can DeRez everything and version that?
If I wanted to find manually DeRez a few hundred of the 6000 files in
my repository and lose the ability to recover old versions, this
would work fine. ;-)
This still does nothing for preserving the non-resource data in a Mac OS file.
Again, the resource fork is only one attribute of a native Mac OS
file that is not preserved by svn in its current form.
(And other platforms have platform-specific metadata as well)
Hence, for svn to be truly cross-platform, there needs to be a way to
store platform-specific file attributes on a per-file basis.
A property per platform is adequate and AppleDouble is adequate for
MacOS files currently.
It's reasonable to define other properties for other platforms as
needed, which should be preserved and ignored by platforms that don't
understand the data.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Pre/Post-processing files on check-in/out
Posted by Augie Fackler <du...@gmail.com>.
On Oct 2, 2007, at 10:50 PM, Jack Repenning wrote:
> On Oct 2, 2007, at 6:55 PM, Steve Sisak wrote:
>
>> Passé or not, I still need to support Mac OS resource forks, types
>> and creators (those are on their way back) and other Mac OS file
>> metadata.
>
> Yeah, I was afraid of that. Had to ask, you know.
>
>> But if you cast the problem as "support for general MIME type
>> decoding", that has general usefulness. Supporting Mac OS files
>> attributes is just a test case.
>
> Hey, I like that "requirements judo"! I agree it puts the key
> parts of the change into somewhere useful to all platforms (I'm
> real paranoid about non-Mac developers breaking our Mac-o-
> syncracies - nothing personal, just an abiding sense of fragility).
>
>> The MIME types for Mac OS file encodings have been set in stone
>> for at least a decade (maybe 2).
>>
>> Matt has proposed file:appledouble for the property which contains
>> the AppleDouble header file (associate with a given data file) --
>> the format of the contents has been defined since A/UX. Unless
>> there are major objections from someone, it's fine with me.
>
> Why isn't the standard name for this property "svn:mime-type"? I
> think there are official standard MIME types for AppleDouble and -
> Single (multipart/appledouble and application/applefile,
> respectively), so anything with that MIME type could, by a Mac
> client, be exploded into the "real" file on checkout, and glommed
> back up on checkin, right?
>
> (Mental note about non-Macophilic file systems, like UFS, on Mac
> platforms....)
QuickTime components rely fairly heavily on resource fork components
and the way we handle this is by storing our resource fork elements
in a rez file which then gets hit with Rez as part of the build
system - maybe you can DeRez everything and version that?
Augie
>
>
>
>
>
> -==-
> Jack Repenning
> jackrepenning@tigris.org
> Project Owner
> SCPlugin
> http://scplugin.tigris.org
> "Subversion for the rest of OS X"
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Pre/Post-processing files on check-in/out
Posted by Steve Sisak <sg...@codewell.com>.
At 7:50 PM -0700 10/2/07, Jack Repenning wrote:
>>The MIME types for Mac OS file encodings have
>>been set in stone for at least a decade (maybe
>>2).
>>
>>Matt has proposed file:appledouble for the
>>property which contains the AppleDouble header
>>file (associate with a given data file) -- the
>>format of the contents has been defined since
>>A/UX. Unless there are major objections from
>>someone, it's fine with me.
>
>Why isn't the standard name for this property "svn:mime-type"?
Because AppleDouble encoding can be applied to _any_ MIME type.
>I think there are official standard MIME types
>for AppleDouble and -Single
>(multipart/appledouble and
>application/applefile, respectively), so
>anything with that MIME type could, by a Mac
>client, be exploded into the "real" file on
>checkout, and glommed back up on checkin, right?
Right -- I mentioned this, and the relevant MIME types in my original post.
The the encodings that result in a single file (a
binary blob) to other platforms have MIME types
and would use svn:mime-type.
AppleDouble encoding is used when the data fork
is useful to, and might be modified on other
platforms, so it would have it's own MIME type,
orthogonal to the AppleDouble encoding but might
still have Mac-specific metadata.
This is the rasion d'être for AppleDouble. In
this case the date file (data fork) contains the
"normal" file and the header file contains the
Mac-specific data.
>(Mental note about non-Macophilic file systems,
>like UFS, on Mac platforms....)
These use AppleDouble -- the "._" file is the
header file, containing the Mac-specific data,
not the resource fork as is often bandied about
by people who are unfamiliar with the spec.
<http://users.phg-online.de/tk/netatalk/doc/Apple/v1/>
An AppleDouble file does not necessarily need to
have a resource fork -- the header file still
preserves:
Real Name
Finder Comment
Icons
Creation Date
Modification Date
Last Backup Date
Attributes
Finder Info
Note that AppleSingle and AppleDouble are the
same format -- they differ in wether the data
fork is stored in a separate file or not,
Matt's solution is to store the AppleDouble
header file as a property of the data file (which
might have its own MIME type) -- therefore a
different property is needed.
Make sense?
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Pre/Post-processing files on check-in/out
Posted by Jack Repenning <jr...@collab.net>.
On Oct 2, 2007, at 6:55 PM, Steve Sisak wrote:
> Passé or not, I still need to support Mac OS resource forks, types
> and creators (those are on their way back) and other Mac OS file
> metadata.
Yeah, I was afraid of that. Had to ask, you know.
> But if you cast the problem as "support for general MIME type
> decoding", that has general usefulness. Supporting Mac OS files
> attributes is just a test case.
Hey, I like that "requirements judo"! I agree it puts the key parts
of the change into somewhere useful to all platforms (I'm real
paranoid about non-Mac developers breaking our Mac-o-syncracies -
nothing personal, just an abiding sense of fragility).
> The MIME types for Mac OS file encodings have been set in stone for
> at least a decade (maybe 2).
>
> Matt has proposed file:appledouble for the property which contains
> the AppleDouble header file (associate with a given data file) --
> the format of the contents has been defined since A/UX. Unless
> there are major objections from someone, it's fine with me.
Why isn't the standard name for this property "svn:mime-type"? I
think there are official standard MIME types for AppleDouble and -
Single (multipart/appledouble and application/applefile,
respectively), so anything with that MIME type could, by a Mac
client, be exploded into the "real" file on checkout, and glommed
back up on checkin, right?
(Mental note about non-Macophilic file systems, like UFS, on Mac
platforms....)
-==-
Jack Repenning
jackrepenning@tigris.org
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Pre/Post-processing files on check-in/out
Posted by Steve Sisak <sg...@codewell.com>.
At 5:16 PM -0700 10/2/07, Jack Repenning wrote:
>On Oct 2, 2007, at 2:00 PM, Steve Sisak wrote:
>
>>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.
>
>All of us in the Mac community (and that
>definitely includes me!) wish this problem would
>get solved. But the CVS solution to this
>problem, which I believe you've been using with
>MacCVS Pro, (called cvswrappers) is widely held
>to have been unsuccessful.
Yes, maintaining a project-specific settings file
has been a perpetual pain and I agree it's a
suboptimal solution.
Now given that I have an existing CVS repository
that's been maintained with MacCVS Pro, I'd like
to get it into svn so that I can clean up the
tree and refactor and modernize the code --
preferably without losing my history.
>There are basically two reasons for this: first,
>the client-side, non-standard processing
>complicates installation and fault analysis, and
>second, so long as it remains specific to what
>is (sadly, we must all admit) a minority
>platform, it will fall out of use, or possibly
>into other, evil uses (as the CVS implementation
>did), and leave those of us dependent upon it
>marooned in "the last working version." And of
>course, Resource Forks are passé, even in the
>Mac world ;-)
Unfortunately, I have code that still has to
build (and, believe it or not, I still get
requests for Mac OS 9 code).
Also, since I write QuickTime components for a
living (my primary business is video input device
drivers), there are places where resources are
_required_ by even current system software.
Passé or not, I still need to support Mac OS
resource forks, types and creators (those are on
their way back) and other Mac OS file metadata.
That said, there are well known encodings for
these (that aren't going to change) and since svn
supports versioned attributes, including MIME
type, and since all of the standard encodings
have well known MIME types, simply tagging
encoded files with their proper MIME type and
building support for those types into the Mac svn
client (if the file is encoded as AppleSingle,
MacBinary or MacBinHex and we're on MacOS, decode
to a native Mac file) would be a complete
solution for me.
I also believe Matt's solution has merit (if a
file in has a file:appledouble property and we're
on MacOS, extract the additional metadata to
create a native Mac file).
This would solve the immediate problem, not
interfere with other platforms, and not open the
cvswrapper can of worms (which could be dealt
with separately).
So, to repeat, my immediate need is to get my
existing repository into svn so I can clean it up
and modernize it, but still be able to extract
the source tree for an old driver because a large
corporation needs it tweaked to work with a
different model of a video cameras because the
old model is no longer available.
>For these reasons, I think most of us would
>rather see extensions that could handle "opaque
>tree structures" (wink wink - bundles!).
I have no problem with that either, however (I think) it's a different problem.
(This isn't an "either or" situation)
>This seems more likely to have actual use in
>non-Mac places as well; it's already cropped up
>in areas like pocket database storage and GPG.
Right.
But if you cast the problem as "support for
general MIME type decoding", that has general
usefulness. Supporting Mac OS files attributes is
just a test case.
>In a cvs2svn context, then, how would you feel
>if cvs2svn were to learn to transform resource
>forks into bundles?
That wouldn't help because it would leave me with a tree that I can't build.
>I believe there are standard mappings and tools
>between file+fork and bundle+resource-file,
>aren't there?
No. There are data fork only resource files that you can put in a bundle.
I'd have to change code to do things the "new"
way so, therefore, I couldn't even build my
current, shipping, tree.
>So even if your app isn't happy about bundles
>rather than resource forks (which I've heard
>some aren't), you'd have a path.
I write QuickTime components, which use resources in required places. period.
And Mac OS files have more extended attributes
than just resources. Look at what is in an
AppleSingle/Double file.
>As for standard properties ... easiest thing in
>the world: set 'em, and don't change your mind
>about what they're called! So long as all the
>providers working on a particular feature can
>agree on the prop name (and values), no one else
>will mind in the least.
That's fine with me.
The MIME types for Mac OS file encodings have
been set in stone for at least a decade (maybe 2).
Matt has proposed file:appledouble for the
property which contains the AppleDouble header
file (associate with a given data file) -- the
format of the contents has been defined since
A/UX. Unless there are major objections from
someone, it's fine with me.
My requirement for converting from CVS to svn is
that I be able to convert my repository and still
be able to extract and build a client delivery
from 2 years ago.
Supporting the standard Mac OS MIME encodings in
the Mac OS svn client, will meet that requirement
completely (wether or not there is a full
cvswrapper equivalent, which I wouldn't object to
as an escape mechanism).
This will get me onto svn and let me modernize my
code while retaining the ability to go back in
history and recover old versions as needed.
I've also got no problem with (and would
contribute to) opaque tree structures, better
support for packages, Open Office OOo files, etc.
>>This identical in concept to svn storing file
>>names in UTF-8 and converting to local
>>conventions on checkout.
>
>Yeah, identical as in "golly, wouldn't it be
>nice if that one were fixed, too???"
I got it working OK (including the .µ extension
on CodeWarrior projects), but I was confused
until I figured out I had to set my locale to
UTF-8 english.
(I had to put the cvs repository on a UFS disk
image and set the encoding to mac-roman, but once
I got both set, the files came across.)
My point here is, that in this case, svn uses a
general format internally (Unicode) and converts
to a local format on checkout (although it ought
to remember the original encoding on a
per-platform basis).
Anyway thanks for the note -- I'll be glad to
help out, but I think we need to handle both the
legacy and forward-looking cases.
Feel free to suggest alternatives.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Pre/Post-processing files on check-in/out
Posted by Steve Sisak <sg...@codewell.com>.
At 9:32 AM +0200 10/3/07, Michael Haggerty wrote:
>FWIW, a couple of months ago I added an option to cvs2svn to unpack
>AppleSingle files during the conversion, but the current code throws
>away everything but the data fork (because SVN doesn't have a way to
>store the other info!) This was helpful to a user who didn't need the
>other resources. This code is in the trunk version of cvs2svn and is
>accessible when starting cvs2svn via the options file method via the
>ctx.decode_apple_single option.
OK, this is very useful -- to support MacCVS Pro, we'd want to add
support for MacBinary and BinHex as well (possibly only in cvs2svn),
but that's just adding well-known code.
>I know this is not a solution to the problem being discussed; I just
>wanted to let you know that it is out there.
Thanks -- I didn't know it was there and it would very much be part
of a solution once we solve the issue of losslessly encoding MacOS
files in a Subversion repository.
Once we get that working, how would you feel about adding a rule for
handling a MacCVS Pro settings file to cvs2svn?
This would automatically set the file encoding, text/binary, eol
mode, etc. type/creator, etc. based on what would have happened had
the project been checked out by MacCVS Pro.
Then, on check-in if the file has a resource fork (which would only
happen if it were encoded in CVS), we put it into svn as AppleSingle,
otherwise, if the file has a type/creator assigned, we check in the
data fork and add an AppleDouble property to preserve that info.
(For that matter, we could just adopt Matt Slott's patch and just
save everything as AppleDouble in the repository)
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Pre/Post-processing files on check-in/out
Posted by Michael Haggerty <mh...@alum.mit.edu>.
Jack Repenning wrote:
> In a cvs2svn context, then, how would you feel if cvs2svn were to learn
> to transform resource forks into bundles? I believe there are standard
> mappings and tools between file+fork and bundle+resource-file, aren't
> there? So even if your app isn't happy about bundles rather than
> resource forks (which I've heard some aren't), you'd have a path.
FWIW, a couple of months ago I added an option to cvs2svn to unpack
AppleSingle files during the conversion, but the current code throws
away everything but the data fork (because SVN doesn't have a way to
store the other info!) This was helpful to a user who didn't need the
other resources. This code is in the trunk version of cvs2svn and is
accessible when starting cvs2svn via the options file method via the
ctx.decode_apple_single option.
I know this is not a solution to the problem being discussed; I just
wanted to let you know that it is out there.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Pre/Post-processing files on check-in/out
Posted by Jack Repenning <jr...@collab.net>.
On Oct 2, 2007, at 2:00 PM, Steve Sisak wrote:
> 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.
All of us in the Mac community (and that definitely includes me!)
wish this problem would get solved. But the CVS solution to this
problem, which I believe you've been using with MacCVS Pro, (called
cvswrappers) is widely held to have been unsuccessful. There are
basically two reasons for this: first, the client-side, non-standard
processing complicates installation and fault analysis, and second,
so long as it remains specific to what is (sadly, we must all admit)
a minority platform, it will fall out of use, or possibly into other,
evil uses (as the CVS implementation did), and leave those of us
dependent upon it marooned in "the last working version." And of
course, Resource Forks are passé, even in the Mac world ;-)
For these reasons, I think most of us would rather see extensions
that could handle "opaque tree structures" (wink wink - bundles!).
This seems more likely to have actual use in non-Mac places as well;
it's already cropped up in areas like pocket database storage and GPG.
In a cvs2svn context, then, how would you feel if cvs2svn were to
learn to transform resource forks into bundles? I believe there are
standard mappings and tools between file+fork and bundle+resource-
file, aren't there? So even if your app isn't happy about bundles
rather than resource forks (which I've heard some aren't), you'd have
a path.
As for standard properties ... easiest thing in the world: set 'em,
and don't change your mind about what they're called! So long as all
the providers working on a particular feature can agree on the prop
name (and values), no one else will mind in the least.
> This identical in concept to svn storing file names in UTF-8 and
> converting to local conventions on checkout.
Yeah, identical as in "golly, wouldn't it be nice if that one were
fixed, too???"
-==-
Jack "who foolishly added over 400 UTF-8 file names to his company's
product" Repenning
jackrepenning@tigris.org
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org