RE: subversion link capability

It's been a while since I worked with Source Safe, but my philosophy on changing tools is that you always do it for a reason. If you import bad habits from the old tool, then you're setting yourself up to make the same mistakes. Except faster. ;)
 
Tool changes are always a good time to refactor code. As a CM guy, I've had to do some 'human engineering' in my past to get managers to 'encourage' their folks to adhere to coding standards, sane project tree layout, etc. Not sure what kind of influence you have, but in my opinion, it's a bad sign when you have to have the same file in two places in source control. Your engineers are just begging for divergance. A better practice (although still hacky) is to have your build scripts copy/stage the files where they need to be, but one tenet of SCM is 'one source'. It's still sloppy code layout/design.
 
That being said, Subversion does support checking in symlinks, but as you said they only work on Unix. This may be a longshot, but at the last place I worked we used Perforce and I checked in a Windows shortcut (the actual .lnk file) for a directory and it seemed to do what I wanted it to do. You couldn't 'browse' the shared directory in the tool, but when you synced your code, it would pull both trees. You might want to give that a try. But I would also lobby heavily to refactor the code to suit the new tool. If not now, when? When your engineers come back with 'It's not a good time' explain to them that it'll never be a good time. The longer they delay, the bigger the job will be.
 
 
-Matt
 
 
-----Original Message-----
From: Grégoire Welraeds [mailto:gregoire.welraeds@side-international.com]
Sent: Thursday, September 08, 2005 5:50 AM
To: users@subversion.tigris.org
Subject: subversion link capability
 
hi there,

I'm bit disappointed by the following problem:
We have our code stored in several subversion repositories (svn installed under debian, version 1.2.0 soon to be migrated to 1.2.3).
We were previously working* with SourceSafe and we have happily migrated some of our project to subversion.
One of the developper contacted me with a question today and I don't know what to tell him.

In a project, he has file y in directory a which is a copy of file x in directory b. These files must be identical to each other when commiting changes to the repository otherwise it could break the application or at least produce some unexpected side effects. In SourceSafe, this was an easy situation as it seems that one can tell SourceSafe that file y is a link to file x and when checking one of the file, the other is automatically updated (I know almost nothing about SourceSafe). Since the project was migrated to svn, he now have to __manually__ copy the file before performing the commit. There is no need to think a long time to understand that this situation is prone to errors.

At first, I told the developper that this was a bad idea to have the same file copied from to directories in the same project and that having a single file in a shared place would be a better design (in this case, the file is a header file). The problem is that since this bad habbit was well supported by source SourceSafe, it seems that there are a lot of similar situations in the code which is still in SourceSafe and that we would like to move to svn. As a consequence, migrating the remaining project would request a lot of work as #include directives are to be checked and makefiles have to be changed. Unfortunatly these projects are several thousand lines of code.
I then had a look at svn:externals property but it only apply to directories, so it is only partially helpfull in our case. I know that subversion supports the Unix symlink but our applications are multi-platforms and mainly developped under windows.

I also thought to implement a post-commit hook which would look in a manually maintained list of copied file and then perform a svn copy each time a commited file is found in the list. But I'm far from convinced that this would be a good solution.

I know I'm not the only one to have the problem (see http://svn.haxx.se/users/archive-2005-05/1342.shtml for example). I haven't find a acceptable solution to this problem and I have not found any reference to a future development that would solve this problem.

Any clue?

TIA and regards,

-- 
Grégoire Welraeds
All code is not created equal.
Qc engineer, S I D E
**********************************************************************
E-mail sent through the Internet is not secure. Western Asset therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Western Asset therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. 
**********************************************************************