6

Our current code base is contained in a versioning system that is old and outdated (Visual Sourcesafe 5.0, mid 1990's), and contains a mix of packages that are no longer used, ones that are being used but no longer updated, and newer code. It is also a mix of 4 languages, and includes libraries for some of our systems (Such as Dialogic, Sun Tzu {clipper}) implementations. This breaks down into the following categories:

  1. Legacy code - No longer used (Systems that have been retired or replaced, etc)
  2. Legacy code - In current use (No intentions for upgrades or minor bug fixes, only major fixes if needed)
  3. Current code - In current use, and will be used for future versions/development
  4. Support libraries - For both legacy and current code (Some of the legacy libraries are no longer available as well)

We would like to migrate this to a newer versioning system as we will be adding more developers, and expanding the reach to include remote programmers.

When migrating, how do you structure it? Do you just perform a dump of all the data and then import it into the new system, or do you segregate according to type before you bring it into the new system? Do you set up a separate area for libraries, or keep them with the relevant packages? Do you separate by language, system, both? A general outline and methodology is fine, it doesn't need to be broken down to individual program level.

2 Answers 2

3

Restructuring everything completely during the migration will probably mean you introduce a high risk of breaking the existing build processes. I would think twice before going that route. The much better alternative is to make 1:1 migration first, and change the structure afterwards, step by step. Any modern versioning system will record the structural changes for you, so if you break something during restructuring, the versioning system will be your safe net.

(Ok, maybe you can leave out the code which is not in use and not under maintenance any more, assumed you can isolate it easily from the other parts. But if not, better migrate it first and delete it afterwards, just like above).

And what about your revision history? When we migrated some years ago from CVS to SVN, keeping the history intact was one of our major requirements - and I can tell you that we never regretted it. So if you see a chance to migrate the history, take it. Changing the structure during the migration will most probably not allow this, but just "dumping all the data and import it into the new system" will not keep the history, either. The better alternative is to create some script (or search the web if someone has already done this for your) which reproduces all commits from the old system into the new one.

One word about the idea of structuring "by language". My team has inherited such repository from another group of developers who thought that structuring "by language" was a good idea. From that experience, I can tell you that its definitely not. At least, not if you want to keep things together which belong together, and the life time of your software is several years. That's because there will be sometimes changes in the language for a subsystem, or one of your subsystems will be extended by another tool or program written in a different language than the rest. And if the folder hierarchy in your production environment will have some similarities to the folder hierachy of your development environment, then structuring "by language" is counter productive, since from the user's point of view the language in which a certain product is written does not really matter.

5
  • The existing build process is check out, change, compile. There are no interdependencies.
    – JohnP
    Jun 10, 2014 at 21:35
  • @JohnP: and what happens with the "compile" step if one of your projects uses a library which is not where the project expects it to be? Or do you have so few shared libs and projects using them that you can move any library in just a few minutes to a different place?
    – Doc Brown
    Jun 10, 2014 at 21:41
  • The latter. Most of the libraries that I'm referencing are Clipper libraries. The library source is in VSS, and the available library is in a path directory so the compiler has it. If one dev changes the library, all devs need to update their copy. Worked ok with 2 devs, but now it will soon become unwieldy.
    – JohnP
    Jun 10, 2014 at 21:44
  • @JohnP: well, if one changes a common library, all others will always have to update the copy - nothing really surprising, and it has nothing to do with the versioning system you are using. The more interesting question is: do you see problems with your current structure? And given you want to change the existing structure: what advantage do you expect in changing the structure without using the new versioning system? The only advantage I can see is that your migration might be a little easier, for the price of loosing the history. Is that really worth it in your case?
    – Doc Brown
    Jun 10, 2014 at 21:57
  • I wish I could give out a +1 for each of the wonderful points @DocBrown makes. Alas, just one +1. Panda sad. Jun 10, 2014 at 22:59
2

It sounds like you've got some flexibility in how you migrate your codebase.

One option would be to make a "clean break" where you set up the new system according to the newer best practices that you want to adhere to. In that case, you can just export everything you want from the old system and import into the new based on whatever structure makes sense. You don't have to tie yourself down to old (90's?) decisions.

The other extreme is to try to migrate to the new system while being strict about keeping as much legacy structure as possible. For example, you might want to import all the Visual Sourcesafe history into the new system (commit messages, authors, etc.) Then you slowly refactor your way into whatever newer structures/organization that you want.

There are pros and cons to both extremes and you can always choose something in the middle. You'll want to consider what kinds of requirements you have (or want) in place. For example:

  • Do you need the full commit history or can you drop it (look at Sourcesafe if necessary)?
  • What level of consistency are your developers (or others accessing the repository) expecting? Will restructuring be a problem?
  • What kinds of differences exist between Sourcesafe and the new version control system? E.g. centralized vs. distributed. How will that affect your decisions?

So as for a general outline and methodology, I'm not sure one really exists for so many unknown variables (such as what system you're moving to, or additional details about your project). If you provide more detail then you might get a better answer.

But at the end of the day it's really up to you and your team to decide what's best.

Just off-hand, based on what detail you provided, I'd personally lean toward the "clean break" extreme and use a DVCS like git or mercurial. Use multiple repositories for each logical grouping/libary/system. Spend a little time to get it all set up in a new, fresh way that will allow your new developers to get started without the baggage of the old structure.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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