Yes, I think location of wc administrative files can be flexible
eventually, because there are only going to be one or two "gateways"
that are used to find administrative info in the working copies. We
just modify those gateways to be smarter, and +poof+.
Getting the gateway guarantee right is of course the catch. I'm
trying to design things that way now, but naturally there will be a
few gotchas when we fully implement the flexibility at some future
point. It'll be okay, though.
-K
Joerg Bullmann <joerg@fontworks.com> writes:
> Hi all,
>
> *** SHORT PERSONAL INTRO
>
> CVS has been part of my jobs and interest for about
> 7 or 8 years now. A few years ago, I wrote MacCVSClient,
> one of the three Mac implementations of CVS and I'm
> still maintaining and it (new version soon! 8-).
>
> In this project, I've given the Mac's resource forks a
> bit of thought as I think without versioning them properly
> there's no fun on the Mac. I have introduced a conversion
> of binary Mac resources to a text line based format that
> CVS can store, diff, and merge.
>
> One of my interests is how to version non text files
> or how to merge non-text files.
>
> I'd like to see SVN
>
> a) being cross platform
> b) addressing binary file formats like Mac resources
>
> from day one!
>
> I hope I can contribute to this at some point. For the
> time being, I'll write and read on this list. As MacCVSClient
> is still under active development, I can't commit to too
> much coding time now but I'd love to work on a MacSVNClient
> later.
>
> END OF SHORT PERSONAL INTRO ***
>
> Some time ago, there was a longish discussion about
> SVN droppings on the mailing list (the droppings in
> SVN'ed folders, not on this list 8-). A few days later
> I wanted to use CVS to control a WebObjects project
> and was glad I had read Karl's and Fred's messages
> here about SVN -> CVS droppings alert!
>
> On the way to work I rethought the issue and came to
> this conclusion:
>
> SVN should not put droppings *in* any DATA OBJECT that
> it versions. For files that is simple. SVN will not
> put any info into them anyway. For folders it is different.
> SVN regards folders at its very own possession. That might
> collide with tools like WebObjects which in turn consider
> some of the folders their own DATA OBJECTS.
>
> So, why can't it be done this way:
>
> DEFAULT: SVN puts an SVN folder (dropping) into each
> folder it controls.
>
> Triggered by file name patterns or some such, SVN
> can be told to put *SOME* of these dropping into other
> safe and non-conflicting places.
>
> sample_pro
> SVN
> sub_SVN
> keep_me_turd_free.SVN
> sub_SVN
> sub_keep_me_turd_free.SVN
> <other SVN stuff>
> <other SVN stuff>
> <other SVN stuff>
> file1
> file2
> file3
> folder1
> SVN
> file21
> file22
> folder2
> SVN
> file31
> file32
> file33
> file34
> keep_me_turd_free
> sub_keep_me_turd_free
> file100
> file101
> file10
> file11
> file12
>
> Note the SVN sub folders in folder1 and folder2
> but not in keep_me_turd_free sub_keep_me_turd_free
> and.
>
> Why keep the SVN folders in the traditional place
> in general? The traditional place (in the folder
> it belongs to) is useful so that you can easily
> copy or move sub projects. Also, this keeps the
> meta data as close as possible to the real data.
>
> The "sub_SVN" folder could contain all those
> SVN droppings that are unwanted in the folders they
> really belong to because the creator of those
> folders considers the folder "off limits" for others.
>
> I see this might look a bit weird at first glance.
> It should be relatively straightforard, though.
> And as SVN has no "backward compatibility"
> load to carry, NOW is the time to act.
>
> Advantages:
>
> *** Only SVN needs to know to keep away from some
> folders. It doesn't need to rely on lots of other
> tools to be written "the clean way" to not touch
> things they don't know. Also, from the other tools'
> point of view, that is not clean at all. They
> consider "their" folder "their own real estate".
>
> Put it this way: folders can be DATA OBJECTS in
> a way.
>
> *** In genereal SVN stores the SVN folders where
> they "belong", i.e. the folder they contain meta
> data for. Only in exceptional cases, the SVN folders
> are moved out of the way just as far as necessary.
>
> Disadvantages:
>
> *** This is slightly more complex than the traditional
> way of storing SVN sub folders in "their" folders,
> no matter what.
>
> What do the others think?
>
> Joerg
Received on Sat Oct 21 14:36:07 2006