Lele Gaifax <lele@nautilus.homeip.net> writes:
> >>>>> "Chris" == Chris Parker <chris@playswithfire.com> writes:
>
> Chris> On Mon, Nov 17, 2003 at 01:00:19AM +0100, Lele Gaifax
> Chris> wrote:
> >> Yes, in ancient NeXT days, there was something like that (was
> >> it CVSPalette?), an IB extension that, using pre/post write
> >> hooks in IB copied .svn/ from the .nib~ folder to the new
> >> .nib/... I remember also a "dirty" hack on CVS modules
> >> functionality, called "wrappers", that in my opinion would be
> >> the right way of dealing with the problem.
>
> Chris> No.
>
> No what?
No way no how no tar wrappers in Subversion. Over my dead body.
> Chris> I can't repeat that enough times. Fitz and a few others are
> Chris> probably wondering just -when- I'm going to read this email
> Chris> and refer you to:
>
> Chris> http://subversion.tigris.org/issues/show_bug.cgi?id=707
>
> Chris> Which would be the Right Way to handle this kind of
> Chris> situation, and get everyone completely away from the
> Chris> wrapper idea.
Yup. I'm a bit behind on my svn email. :)
> I miss your point: issue 707 talks about an "opaque" collection, it
> does not clarify in what way this would be different from the wrapper
> concept. You are apparently against "tar", but I do not see an evident
> reason for which the "storage" of a particular subtree of your repos
> (be it a .nib folder, or a deeper hierachy that, for whatever reasons,
> you want keep zipped+signed in the repository) couldn't be decided by
> the user/developer/admin. I do surely know, by now, that this isn't
> exacly svn' field, but I still consider that some support from it would
> be welcome if not needed.
>
> Chris> People who helped implement the wrapper idea
> Chris> think it's a bad idea. The synchronization issue alone of
> Chris> implementing the wrapper gives most CVS admins fits, and
> Chris> for good reason.
>
> Chris, I do *know*, having used that functionality *while* "people"
> (bbum, primarily) was implementing it :). Sooner or later I will have
> to convert my oldest CVS repos, that used that hack, while the
> NeXTstation keeps booting... :-|
Ask bbum what he thinks about tar wrappers. Better yet, search the
dev@subversion email archives for his comments. Don't make me bring him
over here and *tell* you what he thinks about them. :)
> AFAICT, it was the /implementation/ of the thing that was "dirty", not
> the concept.
Both are dirty.
> Chris> Note that (unfortunately) IB in Panther has the ability to
> Chris> listen for a default for this kind of thing:
>
> Chris> 'defaults write com.apple.InterfaceBuilder
> Chris> VersionControlDirectory "(CVS, .svn)"'
>
> Chris> will allow you to preserve your version control admin
> Chris> directories of choice. You'll still have to manually 'svn
> Chris> add' or 'svn remove' if you put things -in- nibs but IB can
> Chris> at least preserve the directories, limiting the requirement
> Chris> for wrappers use.
>
> Yes, but from a different PoV, this somewhat breaks the admirable
> concept of "app-folders", of which usually the user shouldn't even
> need to know the internal layout. As said, having used it, the
> potential of going out-of-sync is very high ("did I add *every* file
> in the .nib/ folder?" and the like).
Certainly, it's not *perfect*, but it's a reasonable workaround until
someone implements opaque collections.
> Consider the .rtfd/ folders (are those still there?): I can immagine
> that, once I import the first version of the document, I'd prefer that
> in some way svn could understand what I really want: whatever I drop
> in my doc (an image, me saying "hello".snd...), is stored somewhere
> (usually with a serial id as name, not the original) within the .rtfd/
> sub-hierarchy and should be *automatically* considered a "part of the
> document" that was modified. Can you show me a case where you do not
> want to "svn add" that file, *before* committing the folder? Again, I
> know, many think this is a frontend related problem...
And all the reasons you state here are why opaque collections are the
*correct* way of dealing with this problem. Bundled directories will be
dealt with just as you expect them to be dealt with, and on top of that,
you don't lose the ability to diff individual files.
I really hope to see opaque collections implemented in Subversion post
1.0... however, it's most likely going to have to wait until libsvn_wc
is rewritten.
Again, I'm not blowing you off here. Please re-read the mail archives
where we discussed tar wrappers and opaque collections in the past.
-Fitz, who needs to start pasting links to these email discussions into
the 707 issue...
--
Brian W. Fitzpatrick <fitz_at_red-bean.com> http://www.red-bean.com/fitz/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 20 23:33:18 2003