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