Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Let's suppose (for simplicity) that we have an application featuring client and server; is there a better idea to use one repository for both or a pair of separate repositories?
Mixing them will probably make easier to track correlated changes and maintain correlated branches (i.e. protocol evolution), but on the other hand will make the individual development more cluttered...
If you are using git or mercurial, then you might want to look at submodules or subrepositories.
The client, server and their interface files would be in their own repositories, but would be tied together at the super-repository level. This would allow you to do one checkout at the top level and git or hg would check out the appropriate commit of each of the submodules/subrepositories.
By only committing to the super-repository when both client and server were appropriate to each other, the super-repository would only ever give you the option to check out a working system - so you would never try to run the new client against an old server or vice-versa.
Submodules/subrepositories give you all of the advantages of using separate repositories, along with the advantages of a single monolithic repository, at the expense of a little extra complexity.
This answer is not intended to advocate git or hg over other SCMs, it just happens to be that I only know these SCMs well enough to know that this option exists. I don't understand how svn externals work for instance.
Separate!
In fact, I'd probably have three repositories, one for the Client and corresponding client-only libraries, one for the Server (and corresponding libraries), and one for the shared libraries (incorporating the API interfaces that expose the functionality between the two, plus any other shared code). I think that's really the key, the shared code should go into a separate repository of its own. That way you can make sure that the interoperability between your client and server is both always at the same version AND is isolated from the design of each of its consumers.
Obviously, this is not always possible, depending on the particular communication framework you're using, but there's likely to be shared code that dictates the format of the data-transfer objects or the handshake steps in your custom protocol (or some other example).
Assuming you have a fairly decent Continuous Integration and QA setup (a fairly large assumption, in my experience, but one I'm going to make nonetheless. If you don't have a QA department you should at least get some CI) you shouldn't need to use the single-repo pattern as a defense against possible code mis-matches, either your CI server will flag up library-interoperability or your QA team will catch runtime errors (or, even better, your Unit Tests will).
The benefits of split repositories lie in the ability to separately version separate parts of a system. Want to take a copy of last week's Server and run it with this week's Client, to try and lock down the root of a performance issue? No worries.
In Mercurial, this scheme can be used, using -> to denote subrepo relationship:
product -> client -|-> (many components)
|-> shared component A
-> server -|-> (many components)
|-> shared component A
Product has subrepos client, server. Each of those has their components as subrepos, possibly at least one subrepo shared between the two.
Tagging should probably be done on the first two levels, not below that.
Commits are done on the component level, the superrepos effectively track named branches and versions of the product. Named branches/bookmarks are usually better than clone branches for usability (ie trainability) and compatibility with subrepos.
hg tends towards the assumption that superrepos are the product, and commits are done at the top level, but that doesn't work particularly well when multiple products use the same components. :-)
I don't think that this scheme will change much if transitioned to git, but I haven't tried it out in git yet.
This is a configuration management problem, not a revision control problem. As always, a programmer using a screwdriver to hammer in a nail. Work out how you will manage you configurations, the the revision control will take care of itself.
The simplest approach is to use a single repository, so unless you like complexity for complexity's sake, then that should be the default choice in the absence of compelling arguments otherwise.
Is the client and server development going to be carried out by different organisations? Will there be multiple implementations of the client (or server)? Is the client open source and the server implementation secret? If the answer to all these questions is "No", then anything more complex than a single repository is likely to bring only inconvenience for no benefit.
If you do choose to maintain separate codebases, you will need clear policies about how this is administered, in order to avoid incompatibilities and dependency hell. After working through the first few hiccups, you might end up discovering that the safest thing is to always check out both repositories together, build them together, and deploy them together...which obviously defeats the whole purpose of separating them!
Modularity is a nice property to have, but splitting repositories is not a tool to achieve that. As the previous paragraph implies, you can have highly coupled components that are split over multiple codebases (undesirable), and likewise you can have highly modular components within the same codebase (desirable).
On more than one occasion, I have advocated (successfully) for my team to merge existing git repositories, because it simplified development and deployment.
Forget about the repository for a moment. How would you organize the two projects on your machine if you weren't sharing with anyone? How would the rest of the team do it? Would you...
Put all the source files for both client and server in the same directory?
Create a main project directory that contains subdirectories for the client and the server?
Keep the two projects completely separate?
Once you come to some consensus about that as a team, you're ready to check the projects into your code repository. All the revision control tools that I can think of are happy to reproduce any directory structure you like -- they don't care one bit about which file belongs to which project. And the difference between having one repository or two (or six) is usually not that great, aside from minor administrative differences.
For example, with Subversion, the biggest difference between separate repositories for client and server and a single combined repository is in the way the revision numbers change. With a singe repository, the version number will increase each time you commit code to either client or server. With separate repositories, a commit to the server project won't change the head revision number for the client.
