Does Subversion have an analogue to VSS's links?_问答_开发者

I am migrating a Visual SourceSafe code repository to Subversion and I am running into a problem.

Here is a simplified layout of our current source code tree (in VSS):

project_root\
  |-libs\
  |-tools\
  |-arch_1\
  |   |-include
  |   |-source
  |-arch_2\
      |-include
      |-source

My problem is in our two arch_ folders. Each arch_ folder will be built for a different hardware architecture, but the contents of the two folders are practically identical. The files in arch_2 are merely VSS links to the files in arch_1, with only a small handful of exceptions. Work is generally checked into and out of the arch_1 folder, and the VSS links make sure that any code checked in here is updated in the arch_2 folder as well.

Moving to Subversion, is there anything that will behave like VSS's links? That is, is there a way to have two files in separate folders magically associated with one another such that they will always be in sync with each other (changes to one will affect the other as well)?

Note: I know the correct answer here is to fix the build system. The build system on this project was pieced together roughly a decade ago, back when our compiler/build system wasn't intelligent enough to compile the same folder full of source code for two different architectures. Thanks to make and updated compilers, we can re-write the build system to eliminate this dependency on two parallel source folders. However, this will take time that we don't have at the moment (we are losing our license to our VSS server and are being forced to migrate on rather short notice). I am hoping to find a Subversion solution to this problem because at the moment, our time would be much better spent making the migration run smoothly than re-writing the build system (which is next on my to-do list!).

Thank you for your help!

Clarification: I have looked into using externals definitions before, and from what I can tell they can only be used on the directory level. I am looking for something that operates on the file level, as some of our directories have a mix of shared/linked files and non-linked, arc开发者_开发百科hitecture-specific files.

I have looked into using externals definitions before, and from what I can tell they can only be used on the directory level.

Look again. Subversion 1.6 supports file-level externals: http://subversion.apache.org/docs/release-notes/1.6.html#file-externals

You can add the content of arch_1 as an SVN External in arch_2

Update:

File externals are support as of SVN 1.6

External Files

As of Subversion 1.6 you can add single file externals to your working copy using the same syntax as for folders. However, there are some restrictions.

The path to the file external must place the file in an existing versioned folder. In general it makes most sense to place the file directly in the folder that has svn:externals set, but it can be in a versioned sub-folder if necessary. By contrast, directory externals will automatically create any intermediate unversioned folders as required.

The URL for a file external must be in the same repository as the URL that the file external will be inserted into; inter-repository file externals are not supported.

See also: SVN 1.6 Release Notes

The closest thing to this in SVN would be to use Externals.

Externals definitions allow you have:

different subdirectories to come from different locations in a repository, or perhaps from different repositories altogether.

Yes there is a way to do this at least for directories. The feature is called externals http://svnbook.red-bean.com/en/1.0/ch07s03.html its been a while since i've used visual studio but even way back 10 years ago VSS links still work better than SVN externals. However the SVN externals are functional. Your usually best to organize your project into libraries(common code in a base directory) and then you can have the project use externals to the libraries, vs having one project external to another projects subdirectory. Eventually SVN will have externals for files as well as directories http://subversion.tigris.org/issues/show_bug.cgi?id=937