On Apple's Cocoa-dev mailing list recently there have been a couple of
interesting comments from Chris Hanson about problems with storing
version control information in directories in the source tree (like CVS
or Subversion). In particular, on NeXT-derived platforms (as well as
Acorn Archimedes I seem to remember), there are objects ("bundles")
that look like files from the GUI, but are in fact directories with a
special subdirectory hierarchy and special contents.
This would be fine, but for the fact that applications sometimes treat
them exactly the way they would have treated a file... for example,
when saving, they might do the following:
1. Create a new bundle, with a different name.
2. Delete the old bundle.
3. Rename the new bundle so it has the original name.
(Just like a typical "safe" file save routine.)
Trouble is, this procedure trashes Subversion/CVS's version control
information, which wouldn't have happened if it were just a file. Now,
in the case of the example Chris gave (EOModeler, part of Apple's
WebObjects software), Apple have apparently changed their program to
cope with CVS, and will presumably at some point have to do so again to
cope with Subversion (depending on exactly what they changed).
It would seem sensible if Subversion and CVS could provide version
control support for such an object without having to change existing
applications; Chris's idea was to add options to hold version control
information outside of the source tree, but I personally don't think
this is a good idea because of the advantages of having it there.
Perhaps a better solution would be to store version control information
for bundles in the containing directory... e.g. given a tree like the
following:
my-project/
my-bundle.ext/
Contents/
Info.plist
Version.plist
Resources/
(which looks like a single file, my-project/my-bundle.bundle, from the
GUI)
a checked-out copy from CVS might look like
my-project/
CVS/
Entries
Repository
Root
my-bundle.ext/
Entries
Contents/
Entries
Resources/
Entries
my-bundle.ext/
Contents/
Info.plist
Version.plist
Resources/
The top-level Entries file could contain an entry listing my-bundle.ext
as a bundle. This would of course mean changing the way CVS and
Subversion locate their information... they'd have to keep going up the
directory tree until they found a .svn or CVS subdirectory, then check
that it listed the directory they had just come from as a bundle.
(I guess in Subversion, the equivalent of the Entries file would just
list my-bundle.ext as if it were a file? I haven't looked at
Subversion in enough detail yet to figure-out how the working copies
work, other than that you use them like you do in CVS.)
Anyway, I thought I'd throw this into the pot to see if anyone had any
ideas; I might have some time soon to work on this sort of thing, so
it's quite possible that if we have some agreement on how to handle
this I might be able to provide a patch.
Kind regards,
Alastair.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 26 18:48:34 2003