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

RE: shared/linked file support inside repo

From: <bha_at_att.net>
Date: 2005-05-25 04:37:24 CEST

I'm only cross posting this message to the dev because there hasn't been much response on the user list. (Response from Georg is included below). I'd like to submit a proper "Bug Report/Request for Enhancement" for this feature.

Thanks,
Dan

 
Date: Mon, 23 May 2005 11:23:04 +0200
Content-Type: text/plain;
        charset="iso-8859-1"
From: Georg Viehöver <viehoever@sigma-c.de>
Subject: shared/linked file support inside repo

I would like to support this feature request.

I am not saying that I like the idea of shared files (hard links, file sharing): It is usually a sign for too much complexity in the source code organisations, and side effects are hard to control. But lets face it: The feature is out there (UNIX file systems, VSS, ClearCase...), and in my case the lack of this feature caused major headaches when moving to subversion.

Georg

-----Original Message-----
From: bha@att.net [mailto:bha@att.net]
Sent: Friday, May 20, 2005 6:11 AM
To: users@subversion.tigris.org
Subject: RFE: shared/linked file support inside repo

Situation: We're stuck w/ VSS right now, and the only obstacle preventing a move to subversion v1.2 (using FSFS - well done! One down, one to go...) is lack of support for "shared files". I've searched the user and dev lists (and the issue tracker) on this. There are a few workarounds proposed, but they either involve using relatively complex workarounds (like svn:internals w/ post-commit scripts) and/or a major reorg of the entire project tree.

For example, say we have a tree like this:
... /root
        /tools
            /junit
                junit.jar (shared)
        /projectA
            build.xml (must NOT be shared)
            buildCommon.xml (MUST be shared)
            /src...(not shared)
            /test...(not shared)
            /lib
                junit.jar (shared)
                lib3rdPartyA (not shared)

        /projectB
            build.xml (not shared)
            buildCommon.xml (shared)
            /src...(not shared)
            /test...(not shared)
            /lib
                junit.jar (shared)

The problems with the "externals" workarounds and refactoring the tree are well documented in other posts (essentially, I'm not even sure the svn:internal trick works with FSFS. I'm pretty sure it only works for entire directories. Refactoring the tree has major usability impact.)

As per Issue Tracker Guidlines, I'm posting this in order to get help in writing up a proper Issue to submit as a new feature request. I have no idea how difficult this feature would be to implement. The lack of this feature is an impediment for a large number of users who, like myself, hope to move from VSS to subversion. Of course, I'd like to move sooner rather than later, so clues about how soon this feature might be added are appreciated.

First: What to call this feature? I've seen it called "shared files", "file sharing", "internal links", "symbolic links", "tree-internal links", etc. Whatever name we choose should not be confused with Unix style file system symbolic links (even though the purpose is similar).

Second: What behavior? Referring to the example tree above:
1. Individual files can be shared. (In fact, VSS can only share files, not whole directories).

2. Modifications made to /projectA/buildCommon.xml auto-magically appear in /projectB/buildCommon.xml. (The same goes for junit.jar).

3. Deleting or Moving the file /projectA/buildCommon.xml has no effect on /projectB/buildCommon.xml. The reverse is also true.

Thanks,
Dan Rollo

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 25 10:41:02 2005

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.