RE: FW: RE: Roadmap for 1.1

> Whatever we do, we should not implement anything even remotely
resembling VSS shared files, which are semantically similar to Unix
filesystem *hard* links

God no. Those poor VSS shared files with no true home to call their own.

The only use I've made for shared files is with 'library' code common to a number of applications, or modules within an application. In nearly every case it is a whole directory full and it is a real pain in VSS to have to manually share each file (usually missing one). And then some developer in a moment of vapidity adds the missing file manually and we've got a copy that isn't linked to the rest.

Call them symbolic links, call them aliases, I just want //..repos1../library/master/*.(h|cpp|etc) to be available in //..repos2../app2/uselibrary/*.(h|cpp) AND I want commits to ../uselibrary/xyz.h to update the master copy, not branch the local tree.

In this respect, svn:externals is a hack which *should* work, but the commits don't work right. The lovely think about svn:externals is that they can point external to the repository - so I'd also like it if symlinks or whatever were able to point to a different repository. This might be hard to cater for but it would make 'vendor branches' trivial. Just point //../svn.collab.net/subversion/apr/ to symlink to //..svn.apache.org/apr/branches/2.0 and update what the symlink contains when you want a new version. (Effectively I guess the client-side code would run twice, ie the server would have to do the client thing. Authentication pass-through and all ... aargh!)

Actually I'd settle for symlinks being readonly - ie to make changes to the master copy, you must change the master copy. As long as it isn't possible to accidentally commit changes against the symlink and thus fork the source.

> [use tags instead of named revisions]
Yes, this is what I do now, and I'm happier with it than naming revisions, actually. Someone else asked for this one, I'm not sure why.

- Walter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 2 06:01:30 2004