RE: shared/linked file support inside repo
From: Georg Viehöver <viehoever_at_sigma-c.de>
Date: 2005-05-23 11:23:04 CEST
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-----
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:
/projectB
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:
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,
---------------------------------------------------------------------
|
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.