[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

SVN droppings -- or: To turd or not to turd

From: Joerg Bullmann <joerg_at_fontworks.com>
Date: 2000-09-01 04:18:34 CEST

Hi all,


    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


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.

          <other SVN stuff>
        <other SVN stuff>
    <other SVN stuff>

Note the SVN sub folders in folder1 and folder2
but not in keep_me_turd_free sub_keep_me_turd_free

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.


*** 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.


*** 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?

Received on Sat Oct 21 14:36:07 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.