1

I'm developing two programs for a project, one client-side and one server-side, where the client program is in python and the server is in java.

My question is are there guidelines (e.g. by github, subversion, etc.) stating that these two should or should not co-exist in the same git repo?

dtrihinas
  • 446
  • 1
  • 4
  • 11
  • 1
    I'd split client and server side projects. However, this is only my opinion. They may be developed under the same project as well. – awesoon Jan 21 '16 at 13:46
  • thanks @MarounMaroun i've committed code and yes they can but my question is more in the essence of should they? is this wise for a production project? – dtrihinas Jan 21 '16 at 13:47
  • 2
    The fact they're in different languages doesn't matter, but maybe they should be in different repos simply because users of the client and users of the server are different people (or the same people engaged in very different roles) with different needs. For example you wouldn't normally expect a web server and a web browser to be bundled together. But then, they're communicating using a mature standardised protocol, so it's fairly easy to see that they're "different things" – Steve Jessop Jan 21 '16 at 13:47
  • 1
    If one works independently of each other, sure. In the case of gitHUB, that website will insist on classifying the repo as being in one language or the other. Anybody's guess where that domino falls, but shouldn't affect operability. – Lori Jan 21 '16 at 13:50
  • Note in [this article](https://www.perforce.com/blog/110607/how-do-they-do-it-googles-one-server-trick) it states that "A single large \[perforce\] depot holds most of Google’s projects"; these are projects developed in [different languages](https://www.quora.com/Which-programming-languages-does-Google-use-internally). You can hold things in one repo, or not. It's totally up to your requirements and preferences. – Andy Turner Jan 21 '16 at 13:50
  • @AndyTurner, what works well with Perforce doesn't necessarily work well with Git. Users of Subversion, for example, often put many applications into a single repository. But this is generally discouraged (for good reason) with Git. – ChrisGPT was on strike Jan 21 '16 at 13:52
  • @Chris What is that good reason? – Andy Turner Jan 21 '16 at 13:53
  • @AndyTurner, IMO the biggest is that you can't clone a subdirectory of a Git repository, so your local repo will contain all projects. (There is [sparse checkout](http://stackoverflow.com/a/13738951/354577), but the `.git/` directory will still include the whole repo.) But it _does_ have good support for _combining smaller repositories_, e.g. using submodules or subtrees. Git performance also decreases as a function of overall repo size, number of files, and number of commits. For an extreme case, [see Facebook](http://thread.gmane.org/gmane.comp.version-control.git/189776). – ChrisGPT was on strike Jan 21 '16 at 14:11
  • @Chris sure, there is the size issue, and yes, not being able to check out subdirectories might be an annoyance. But taking the question as asking whether code written in different languages ought to be in different repos, I still say not necessarily: it depends upon your requirements (e.g. size and desire to check out subdirectories) and preferences. If I did require separate repos, I would split them on a functional basis, not language. – Andy Turner Jan 21 '16 at 14:14
  • @AndyTurner, I agree that repositories shouldn't be arbitrarily split along language lines. But an article saying that Google stores all of its repositories in a single Perforce depot is meaningless in a conversation about Git. These are very different systems, and best practices for one don't necessarily transfer to the other. – ChrisGPT was on strike Jan 21 '16 at 14:24
  • 1
    In this case, most of the things discussed above are irrelevant. This is stated as Git and there are two separate (other than a shared interface) projects developed in separate languages. There's no reason to keep them together. – Ross Drew Jan 21 '16 at 15:00

1 Answers1

2

Since you'll generally be compiling and distributing them separately, I'd suggest separate repos. They are -in that case- separate projects.

One artifact per project keeps thing nice and simple. One build command per output. Having multiple projects in one repo means a complex directory structure, lots of build tool customisation (in the case of,say, Maven) and possibly complex build commands. It does mean -however- that any communication changes will need to be made to two projects but as client and server are in different languages you'd need to do that anyway.

Ross Drew
  • 8,163
  • 2
  • 41
  • 53