SVN management on a project that uses absolute paths.

Question

I've heard before that including project and workspace/solution files in source control is generally bad practice anyhow but I wanted to get feedback on the best way to handle this situation.

My work has requested I set up a source control service for my department (which i've been asking for since day 1, 3 years ago). My biggest hurdles are as follows.

We keep a snapshot of the latest release on a network SMB share, use a tag and manually update it? can multiple people maintain this working copy at once or does the folder associate with the creator only?

All of our "project" files (containing file manifests, build info, etc.) uses absolute paths. This is a real pain if I use c:\myproject and a co-worker uses c:\MaiPrjLolKeke I've heard various arguments against the usage of putting project files under source control anyhow, but then if a new file gets added to the project what's the best way to notify co-workers that new files might have to be added?

Answer 1

The problem is not project files in source. The problem is the hardcoded paths in the project files.

You can either use relative paths or use environment variables for this.

For example, you can use a common "root" for your include files and a common "root" for other third party libraries. The hierarchy UNDER the roots of those should be the same.

This is generally used in many places I have worked and it is normally how you can point to third party libraries. It also solves the issue of having multiple versions of some set of files on a machine. By changing one environment variable (in a build script or otherwise) you can cater to specific targets/builds.

As to your other question - it is not exactly clear what you are saying. I think you are asking if multiple people check out to the same shared path/network share. That is not a good idea. You can all have your own working set/working copy of the source files and SVN by default does not "Lock" files so you can work on them simultaneously. You jut have to get into the practice of updating/getting the latest source/changes.

EDIT - as another poster said (and I repeat it here so you won't miss it) -

Solution and/or project files in source control is NOT bad practice.

EDIT:

Here is another solution - not sure if anyone else already suggested it.

create a mapping to some other place in your path structure and make it a network drive - like x:\

If everyone does this they can keep their directory structures how they like and still use the same project files. No need for dummy ones.

For example, if developer A has

C:\development\project\blah Map X:\project to c:\development\project

and developer 2 has: C:\my documents\user\Visual studio\etc..., she maps X:\ to that path.

Viola!

C:\

Answer 2

Set up your build files to use relative paths.

Ideally, you should be able to checkout a copy from SVN at any time (and into any folder), run the build script, run the automated tests, and be up and running immediately. If you can't do that, you're doing something wrong.

(Yeah, you may also need to set up the operating system, the database server, the web server, the programming language, and the IDE, first. But once the global infrastructure is already there, you should be able to hit the ground running at any time and from any location.)

Answer 3

If you have hard-coded paths in your projects, then you need to standardise on one so you can all work together. This may mean you all have to change to use "c:\work" or "C:\dev", but that's a small price to pay for making everything 'just work'.

If you absolutely cannot do this, then I recommend junction - this sets up links from one directory to another. You can all check in files for the 'common' path, but still access it from your own preferred path. Not the best, but workable.

If you can use relative paths, then you're in shared-working nirvana. Really try for this as it'll just solve all your problems.

If you have problems with referenced files that must be in a particular directory relative to your other projects, (eg a common set that sits in c:\include for example) then junction it to the location you check it out to, and you'll be ok assuming you can handle the discipline that managing that requires. Or you could use svn:externals to check out the common files to a hard-coded path for you.

PS. putting project files in your SCM is not a bad practice, I think everyone does it, but all paths must be relative to the project itself, so you can check the whole lot out anywhere you like.

Answer 4

I have to deal with a similar configuration (project files in the SVN repository.) The primary issue is that someone will "fix" the path for their system and then check in the changes (which kills everyone else's project or forces (evil) merging.)

One solution which works for use is to store a template (e.g. TEMPLATE.project) in the repository and add (.project) to SVN:ignore. This allows each developer to check out a template of the required file but not easily check in unintended changes.

Another way to address the issue with .classpath is to use UserLibraries to include all your third party libraries. This allows developers to store them wherever they like and configure a mapping in Eclipse.