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.

I'm working on a content synchronisation module for Drupal. There is a server module, which sits on ona website and exposes content via a web service. There is a also a client module, which sits on a different site and fetches and imports the content at regular intervals.

The server is created on Drupal 6. The client is created on Drupal 7. There is going to be a need for a Druapl 7 version of the server. And then there will be a need for a Drupal 8 version of both the client and the server once it is released next year.

I'm fairly new to git and source control, so I was wondering what is the best way to setup the git repositories? Would it be a case of having a separate repository for each instance, i.e:

Drupal 6 server = 1 repository
Drupal 6 client = 1 repository
Drupal 7 server = 1 repository
Drupal 7 client = 1 repository
etc 

Or would it make more sense to have one repository for the server and another for the client then create branches for each Drupal version?

Currently I have 2 repositories - one for the client and another for the server.

share|improve this question
add comment

2 Answers

up vote 6 down vote accepted

Unless the project is really huge, I'd go for single repository with subdirectories for server and client and create a branch for each version. You can still have multiple copies of the repository in case you want access multiple versions at the same time.

By maintaining multiple repositories, you'd make transferring changes harder than necessary (rebase is easier than applying patches). In the (improbable) case there'll no changes to be applied to multiple versions, you still lose nothing...

Moreover, you can always switch to multiple repositories: Just clone the repo and remove the branches you don't want. Going the other way round is harder.

I'd go for multiple repos only if the server and client share nothing or if the code is really huge.

share|improve this answer
    
This is the way I'm going to go because Drupal stores different versions as branches. I'd +1 too but need 15 rep! –  littledynamo Nov 13 '12 at 12:04
add comment

I have seen and worked with such variations. Everything in one folder with subfolders for server and client or one repo each. I prefer the single repo for every main part of the project.

In case of big version changes I would simply create new repos too. Definitely not have different branches for them. While branches are powerful for implementation of new functionality and maybe one permanent deployment branch, I always avoid having too many of them run parallel for a long time. You will always have to maintain them (do rebases when the master branch changed etc), so keep the basic structuring as simple as possible. Having an extra repo is (in my humble opinion) less painful than juggling branches in different states. Especially if client and server don't share much code.

I don't know much about Drupal and how strong the differences between versions are. So my point to prefer different repos is based more on my experience with Rails. Between versions there are sometimes big differences in things like how files are named or the folder structure (eg asset pipeline) which makes it more comfortable to create a new repo. Drupal (or any other framework) may have less differences, then it would be ok to just go on within the existing repo.

share|improve this answer
1  
Thanks. It's interesting because I've just discovered that Drupal Core modules store separate versions as branches. I think it makes sense for me to mimic that structure. I would +1 but need 15 rep! –  littledynamo Nov 13 '12 at 12:03
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.