2

My team has a mix of software developers and scientists, and version control has been messy in the past. We're trying to do better, which leads me to ask this question.

We have a central codebase for a subset of projects that includes code for different tools all sharing common algorithms. Let's call that U1. There are fragmented tools disconnected from this codebase that should one day be integrated into it, because of common algorithms and other aspects of them.

A fragmented tool, let's call it F1, is probably not going to be merged into U1 for quite a while, but we still need to add it to version control. A scientist has been developing it on their PC, backing up snapshots, but we want a better backup/record system than that, thus the need for version control. Should F1 be stored as a branch in the same repo as U1, or if not, then where should F1 be stored?

On the one hand I'd say no to that question because F1 is not actually a branch of U1, it is essentially a separate tree. On the other hand, F1 is very similar to U1 in some ways and is just an extension of what U1 does. Someone looking for F1 would reasonably look in the same repository as U1. My concern with storing F1 as a branch is that we've had problems before with 'disconnected branches', branches that were committed with no ancestral relation to anything else in the repository. Obviously the best thing to do is merge F1 into U1 and call it a day, but I'm wondering where we should version control F1 until that happens.

  • 1
    Obviously the best thing to do is merge F1 into U1 and call it a day, but I'm wondering where we should version control F1 until that happens -- Didn't you already say that F1 is essentially a separate tree? If that is so, what prevents you from storing F1 in its own repository until you get its functionality subsumed into U1? – Robert Harvey Apr 8 at 21:45
  • @RobertHarvey that is an option but we prefer to avoid it, as repositories have been serving as high-level project organization and all the projects and programs I'm working with in this case are actually within the same high-level project. So, unless it's too messy or problematic to organize F1 and U1 in the same repo, we'd prefer to keep them together and avoid more repos than we already have. – cr0 Apr 9 at 1:00
2

For subversion, it is common to have separated projects in one repository as subdirectories. And, there is no real distinction between branch and subdirectory, so it is only a matter of convention. In most cases it ends up like

U1/trunk/
U1/branches/...
U1/tags/...
F1/trunk/
F1/branches/...
F1/tags/...

If you have already used root for U1 you could make a special subdirectory for them next to trunk etc. Or make one-time moving of things to the new hierarchy.

Basically, it does not matter much technically. Just make sure that the F1's history is tracked some way. And, again, keeping it in same repository as a branch/subdirectory is totally acceptable for svn.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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