You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by William Uther <wi...@cs.cmu.edu> on 2002/02/17 07:09:55 UTC
Extra 'Cleanup'?
Hi,
I've been playing around with subversion on Mac OS X. Mac OS X has a
concept called a 'bundle'. Basically, this is just a directory that the
UI treats as a file. Versioning these things is not hard - you just add
them recursively.
The problem I'm having is that one of the programs I have to edit these
bundles (Interface Builder) wants to own the entire bundle. When you save
the bundle it moves the old one and creates a new one from scratch. This
wipes out the .svn directories. Grrrrr.
Anyway, I can see two solutions. The first is a special form of cleanup
that adds the .svn directories back in. Given the data from the .svn
directory of the parent folder, and repository access, subversion should
be able to recreate the .svn directories in the children (assuming that
there have been no moves, copies, adds or deletes).
The second solution is to add a special type of directory to subversion.
This would be a 'verbatim' directory. When a directory is marked as
verbatim the 'verbatim' flag (property?) is turned on in the parent.
Verbatim directories do not have '.svn' folders. Each time the directory
is checked in, the entire hierarchy rooted at that directory is checked
in. Any new files are automatically added. Missing files are
automatically deleted. Files are treated as binary. (It could honour the
svn:ignore property of the parent, but would not have any entries file to
store its own properties.)
The lack of .svn folders means some things: You cannot check out a
verbatim directory directly, only as the child of another directory you're
checking out. You must move out of the 'verbatim' hierarchy to update.
You might consider having the previous version of the verbatim hierarchy
in the parent's text-base. That still allows for off-line diffing, etc.
I think the first solution is probably significantly less work :).
Anyway, this is just verbiage without patches, so feel free to ignore. :)
Later,
\x/ill :-}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extra 'Cleanup'?
Posted by Lele Gaifax <le...@seldati.it>.
>>>>> On Wed, 20 Feb 2002 05:10:27 -0800, Chris Parker <ch...@playswithfire.com> said:
CP> Argh. Honest, I was trying to resist... On Tue, Feb 19, 2002
CP> at 12:29:03PM -0600, Karl Fogel wrote:
>> This is not a general solution to the problem, but then again,
>> I've really only heard of this problem coming up regularly with
>> the OS X interface builder anyway:
>>
>> I think they finally caved in and added special support to
>> avoid clobbering CVS/ subdirs, and that they may be willing to
>> do the same for Subversion, perhaps generalizing the support in
>> some way so the problem doesn't keep coming up for future
>> systems. Frankly, I'd prefer that to the burden of maintaining
>> "verbatim directory" code in the Subversion client libraries...
CP> Yes, there is code in IB to not stomp the CVS/ subdirectory,
CP> but this really isn't the Right Thing. IB expects to have
CP> control of what it's idea of a document is, and I don't find
CP> that unreasonable. The fact that in this case its notion of a
CP> document happens to be a folder shouldn't really be that
CP> important. IB having to rev every time some new version
CP> control system comes along doesn't seem like the Right Thing
CP> either, so something else should probably be developed. What,
CP> exactly, is the question.
CP> This becomes slightly more interesting in the case of the
CP> .rtfd documents that TextEdit produces - although the name of
CP> the directory is (say) foo.rtfd, it contains any number of
CP> filenames, none of which you may know the name of - TextEdit
CP> and NSFileWrapper manage that behind the scenes.
CP> So the question I think becomes "Is there a way to treat these
CP> things as 'atomic' without dumping their metadata someplace
CP> else?"
I seem to remember a CVSPalette for IB that basically attached itself
in the "on-write-hook" chain: upon saving the .nib it simply copy the
CVS/ from the backup to the new .nib directory. IIRC, also other NeXT
tools as TextEdit did have a similar feature of hooking special
behaviour... nice system !-)
Given that the file it contains are (were? I do not know if recent
incarnations of The Thing changed to some text format...) mostly
binary, I later switched to the CVS "wrappers" approach (I think it
was introduced mainly to handle IB peculiarity :-), similar to what
you call "opaque collection". That simply "versioned" a .tar.gz of the
directory, that did not even had its CVS/ subdir.
I think this is a better approch. It can handle a wider range of
cases: for example, it would be useful to perform an arbitrary command
on a given file maybe to "normalize" it (to impose consistent
formatting through something like indent?) or to translate in some
other format more suitable to be merged by humans (for example I tried
hard to keep Delphi .dfm binary file under CVS, but translating them
in their text-format on commit, and back to binary on extraction:
since on CVS this was a server operation, and the server was on
GNU/Linux, I had to it use `dosemu'... finally Delphi5 removed the
hassle permitting to keep the .dfm always in text-format, but that's
another story).
bye, lele.
--
nickname: Lele Gaifax | Quando vivro' di quello che ho pensato ieri
real: Emanuele Gaifas | comincero' ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extra 'Cleanup'?
Posted by Chris Parker <ch...@playswithfire.com>.
Argh. Honest, I was trying to resist...
On Tue, Feb 19, 2002 at 12:29:03PM -0600, Karl Fogel wrote:
> This is not a general solution to the problem, but then again, I've
> really only heard of this problem coming up regularly with the OS X
> interface builder anyway:
>
> I think they finally caved in and added special support to avoid
> clobbering CVS/ subdirs, and that they may be willing to do the same
> for Subversion, perhaps generalizing the support in some way so the
> problem doesn't keep coming up for future systems. Frankly, I'd
> prefer that to the burden of maintaining "verbatim directory" code in
> the Subversion client libraries...
Yes, there is code in IB to not stomp the CVS/ subdirectory, but this
really isn't the Right Thing. IB expects to have control of what it's
idea of a document is, and I don't find that unreasonable. The fact
that in this case its notion of a document happens to be a folder
shouldn't really be that important. IB having to rev every time some
new version control system comes along doesn't seem like the Right
Thing either, so something else should probably be developed. What,
exactly, is the question.
This becomes slightly more interesting in the case of the .rtfd
documents that TextEdit produces - although the name of the directory
is (say) foo.rtfd, it contains any number of filenames, none of which
you may know the name of - TextEdit and NSFileWrapper manage that
behind the scenes.
So the question I think becomes "Is there a way to treat these things
as 'atomic' without dumping their metadata someplace else?"
> Brian Fitzpatrick <fi...@apple.com> may know more about this (CC'd)?
In my other email address I work for the fruit company also... some
ideas have been kicked about, but here is my "Reader's Digest
Condensed Version" of some of the discussion:
Subversion's version numbering scheme solves the problems of getting
mismatched .nib elements inside the nib - you've either got version
619 of the project or version 618, but you won't get something
"inbetween" like you might with CVS.
But... you can't necessarily know anything about what's underneath
that top level directory at all.
The last I'd heard (the last email going around on this subject was 4
Feb) was that it'd be nifty to tag directories that should be 'atomic'
as 'opaque collections.' The client would then know that if it hit a
directory with this opaque collection property, it would basically do
a diff -r on that collection doing the diffs it can, removing files
that aren't in the collection anymore and adding the files that have
appeared, the metadata for these operations being stored in the .svn/
for the containing directory.
This gets the .svn/ data out of the document bundle, still gives you
effective versioning on the thing, as well as preserving information
about operations in a reasonable manner, leaving management of the
bundle contents to the owning application.
The added bonus seems to be that it also means you're not storing the
nib as a big wrapped blob in the repository.
Greg, Garrett, Bill, anyone else want to cover anything I've missed?
.chris
--
Chris Parker
Itinerant Graduate Student, Rensselaer Polytechnic Institute
Cocoa Frameworks Engineer, Apple Computer, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extra 'Cleanup'?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
This is not a general solution to the problem, but then again, I've
really only heard of this problem coming up regularly with the OS X
interface builder anyway:
I think they finally caved in and added special support to avoid
clobbering CVS/ subdirs, and that they may be willing to do the same
for Subversion, perhaps generalizing the support in some way so the
problem doesn't keep coming up for future systems. Frankly, I'd
prefer that to the burden of maintaining "verbatim directory" code in
the Subversion client libraries...
Brian Fitzpatrick <fi...@apple.com> may know more about this (CC'd)?
-K
William Uther <wi...@cs.cmu.edu> writes:
> I've been playing around with subversion on Mac OS X. Mac OS X has a
> concept called a 'bundle'. Basically, this is just a directory that the
> UI treats as a file. Versioning these things is not hard - you just add
> them recursively.
>
> The problem I'm having is that one of the programs I have to edit these
> bundles (Interface Builder) wants to own the entire bundle. When you save
> the bundle it moves the old one and creates a new one from scratch. This
> wipes out the .svn directories. Grrrrr.
>
> Anyway, I can see two solutions. The first is a special form of cleanup
> that adds the .svn directories back in. Given the data from the .svn
> directory of the parent folder, and repository access, subversion should
> be able to recreate the .svn directories in the children (assuming that
> there have been no moves, copies, adds or deletes).
>
> The second solution is to add a special type of directory to subversion.
> This would be a 'verbatim' directory. When a directory is marked as
> verbatim the 'verbatim' flag (property?) is turned on in the parent.
> Verbatim directories do not have '.svn' folders. Each time the directory
> is checked in, the entire hierarchy rooted at that directory is checked
> in. Any new files are automatically added. Missing files are
> automatically deleted. Files are treated as binary. (It could honour the
> svn:ignore property of the parent, but would not have any entries file to
> store its own properties.)
>
> The lack of .svn folders means some things: You cannot check out a
> verbatim directory directly, only as the child of another directory you're
> checking out. You must move out of the 'verbatim' hierarchy to update.
> You might consider having the previous version of the verbatim hierarchy
> in the parent's text-base. That still allows for off-line diffing, etc.
>
> I think the first solution is probably significantly less work :).
> Anyway, this is just verbiage without patches, so feel free to ignore. :)
>
> Later,
>
> \x/ill :-}
>
>
>
> ---------------------------------------------------------------------
> 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