Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Currently we are using Source Safe and have started migration to Subversion. All of our external SDK's(> 500 MB) are held in Source Safe right now, and I am looking for ways to move them from VSS to a repository.

We have C++ (mostly), C# (many), Java (few) projects. Hundreds of projects, all running on Windows.

I looked at a couple of dependency managers but I'm not satisfied:

  • NuGet - good for .Net but painful for C++
  • Ivy - not look in depth, but doesn't seem acceptable for C++

First question: what else should I check? It should be easy to use for a front-end developer. Best case is a simple build within the IDE.


Currently I am inclined to this solution:

Allocate some rarely used drive, like S: and declare it as 'DEV HOME'.

Then place externals here:

S:\SDK\boost\1.30\...
S:\SDK\boost\1.45\...
S:\SDK\oracle\agile_9.0.0.0\...
S:\SDK\IBM\lotus_8.0\...
S:\SDK\IBM\lotus_9.0\...
S:\Tools\NuGet\nuget.exe
S:\Tools\clr\gacutil.exe

Autobuild machine will hold mastercopy of this 'DEV HOME'. Every developer should copy necessary SDKs from autobuild machine to local and create a 'fake' disk with subst.

I can't find any big problems with this solution:

  • Branches. Projects in different branches contain references to different versions of SDK (boost for example)
  • Version of external component will not change too frequently, so there will not be hundreds of, say, boost versions.
  • Easy for developers to setup.
  • Absolute paths supported by any tool.

Minor problems:

  • Personally for me it is not beautiful solution.
  • Disk (S:) can be busy
  • Can't be done in Linux (but currently we're not interested in it)

Second question: what problems can you see with this solution?

share|improve this question
2  
I'd strongly suggest to skip subversion and migrate straight to a distributed version control system. You are likely to end up migrating to one of them in future anyway when people find about some of their additional features, so you might as well save yourself learning subversion. –  Jan Hudec Apr 9 '13 at 7:36
    
I think about it, but reckon that SVN more suited for our needs. Main reason - DVCS cant deny read access for some projects. This feature absolutely demand by management. –  Sergey Azarkevich Apr 9 '13 at 8:09
1  
Also, our developers not ready for DVCS features. We start migrate and using of SVN about 1.5 years ago and developers (well... ~70% of them) still do not want know something other than update/commit. Merge, patch, switch, revert? No way... –  Sergey Azarkevich Apr 9 '13 at 8:18
1  
DVCS can deny read access for anything. On the central server. CVCS can't deny read access on the client either. –  Jan Hudec Apr 9 '13 at 8:26
1  
You may want to check DFS and Offline Files. Keeping directories in sync is a solved problem; don't reinvent the wheel. –  MSalters Jul 22 '13 at 10:34
show 4 more comments

2 Answers

The biggest problem with a mapped drive is that it fails utterly if someone decides to use that drive for something else. You might claim that won't happen; I might counter that claim with lots of experience and cynicism and say “Hah!”

Virtually all development tools these days are perfectly happy to work with almost everything done with relative paths. Once you use them, you should find that you can avoid committing any absolute paths to the code repository (or repositories) and everything will be much neater. The only parts that get absolute paths are things like IDE configuration files, and they're the sort of thing that it is best to leave uncommitted. (You wouldn't want to share the arrangement of tool windows? So why share the paths?)


For dependency managers, I suggest using a native one for each language. Use a good product like NuGet just for what it is good at rather than trying to wedge everything into one global magic tool. “Jack of all trades; master of none.” (Also, dependency management with C++ just isn't as advanced as with C# and Java. But you can do cooler tricks with alternative implementation bindings instead…)

For source code management, I'd advise keeping as much binary data out of the repository as possible. Only commit files that are the originals, not that are copies of something held elsewhere in the world.

share|improve this answer
    
Busy disk is not a problem. This is not open source or distributed project. If disk used - developer should 'unuse' it. –  Sergey Azarkevich Jul 23 '13 at 4:32
    
About absolute paths. I do not see big difference if in repository stored absolute paths or relative, but out of repository. In first case dependencies should be in fixed position (Q:) in second case they should be bound to working copy (if working copy moved, then externals also should be moved...) –  Sergey Azarkevich Jul 23 '13 at 4:36
    
And about dep. managers. I have no objections using different dep.managers for different platforms. But I simply do not known any for C++. Also I don't understand what you means in "alternative implementation bindings". Can yoy geve me clues for search? –  Sergey Azarkevich Jul 23 '13 at 4:39
add comment

To answer your second question - the main issue with using a shared drive for hosting code is that the performance won't be optimal. You will probably come across concurrency problems and speed in general. I would recommend that you either have each's project's dependencies stored with the SVN repo, but outside of the main trunk folder (to avoid duplication on branching). Or if you have lots of common dependencies, you could have a separate repository for that and use SVN's "externals" to manage it.

In terms of dependency manager no-one can recommend one to you that will cater for all of your individual needs, each one has benefits and trade offs, especially considering your large range of languages. Back to google I'm afraid :)

share|improve this answer
    
1. It was planned to copy all externals from 'master copy' share to local computer. But actually developers prefer use mapping to network share... So, performance issues can have place here. 2. Problem with svn:externals in big size of external dependencies. Currently it is 2GB. Having +2GB in every checked out branch is not enjoyed us... Some developers has > 10 checked out working copies. Place dependencies outside of trunk look equally to using dedicated disk... –  Sergey Azarkevich Jul 22 '13 at 8:14
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.