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 am migrating a 10-years-old big CVS repository to Git. It seemed obvious to split this multiple-projects repository into several Git ones. But the decision-makers are used to CVS, therefore their point of view is influenced by CVS philosophy.

To convince them to migrate from one CVS repo to different Git repositories I need to give them some arguments.

When I speak with mates working on Git repo for years, they say that using multiple Git repo is the way to use Git. I do not know really why (they give me some ideas). I am a newbie in this field so I ask here my question.

What are the arguments to use multiple Git repositories instead of a single one containing different applications and libraries from different teams?

I have already listed:



EDIT:

share|improve this question
1  
Where is the question actually? –  Jim Martens Jul 31 '13 at 14:47
    
@JimMartens: What are the reasons Git users usually use several Git repositories while CVS users use a single one? (one Git repo per deliverable module?) Thanks for your comment, I may change the question explanation... Finally I changed the title ;-) –  olibre Jul 31 '13 at 15:06
1  
Do they? We used to have different SVN repositories for different projects. –  Leonardo Herrera Jul 31 '13 at 15:17
1  
Who says that git users, use multiple smaller repositories? –  m3th0dman Jul 31 '13 at 16:17
2  
show 4 more comments

7 Answers

up vote 6 down vote accepted

They want [something that can] show their changes across all projects instead of trying to remember what project they made a change [to].

Sourcetree (a free-as-in-beer GUI Git frontend) allows you to register multiple repositories, organise them into logical groups, and then view status across all of them at once: screenshot

I am not affiliated with them in any way.

share|improve this answer
add comment

Git tends to experience performance problems when used with large repositories.

To quote Linus:

And git obviously doesn't have that kind of model at all. Git
fundamnetally never really looks at less than the whole repo. Even if you limit things a bit (ie check out just a portion, or have the history go back just a bit), git ends up still always caring about the whole thing, and carrying the knowledge around.

So git scales really badly if you force it to look at everything as one huge repository. I don't think that part is really fixable, although we can probably improve on it.

Emphasis mine. That's not to say your company's version control repository is "large," but this is one reason people tend to avoid large repositories within Git.

share|improve this answer
    
Thanks for the link ;) This is the reason why Google limits the code.google.com Git repositories to 4 GB. Cheers –  olibre Aug 1 '13 at 14:21
    
So basically using multiple repos is just a perf optimization? –  Eamon Nerbonne Nov 15 '13 at 17:01
    
It's a performance optimization, but I'm not sure if it's only a performance optimization. Per AProgrammer's answer it's also a way to represent the notion of a "module" in git. –  Brian Nov 15 '13 at 18:59
add comment

TL;DR; the equivalent of a git repository is a CVS module, not a CVS repository.

CVS is designed with a notion of modules being a subdivision of a repository, and it is common to use CVS repositories with several modules having a quite independent life. As an example, it is easy to have branches specific to one module and not present in another.

git has not be designed with a notion of module, each git repository is limited to one module in CVS term. When you create a branch, it is valid for the whole repository.

Thus, if you want to import a CVS repository with several modules in git, you better create a repository per module, especially if the modules have a more or less independent life and don't shares things like branch and labels. (Due to different usage patterns of branches in CVS and git, you may even investigate the usefulness to have one repository per CVS branch; but for a migration from CVS to git, it is probable that your workflow will at the start be similar enough to a CVS workflow that it doesn't worth the pain).

share|improve this answer
add comment

If you're willing to play ball with them in order to appease, you could set it up this way. Or this method. Other than that, I think they're just expecting a single point of entry into the system to access assets.

Depending on access needs, the separated GIT repos might still be the better way to go, as "John Smith" may need access to certain data, but not other data. While "Suzy Que" may be a sys admin needing access to everything.

If you go with a single repo, you might run into issues with your internal access requirements. If it's an "everybody gets full access" type of thing, then I could possibly see their point of view.

share|improve this answer
9  
Would be a much better answer if you summarize the methods in the links. –  Rig Jul 31 '13 at 15:40
    
At present, each developer has access to any source code within the unique CVS repository. So they do not care about developers having access to any source code within a unique Git repo. But this is a good advantage to switch to multiple Git repositories, thanks ;-) However I did not understand what you mean about your branching models as each application has its own branches/tags. Cheers –  olibre Jul 31 '13 at 15:47
    
Hi Will. After reading again your answer I understand better what you mean (I mean the last two paragraphs). This is a good point to underlying +1 Please could you give more explanation on your first paragraph instead of putting this links? Or you may remove your first paragraph... ;) Cheers –  olibre Nov 18 '13 at 8:37
add comment

Git migration help page from Eclipse suggests to reorganize the CVS/SVN directory tree into multiple Git repositories:

Now is a great time to refactor your code structure. Map the current CVS/SVN directories, modules, plugins, etc. to their new home in Git. Typically, one Git repository (.git) is created for each logical grouping of code -- a project, a component, and so on.

The arguments:

The trade-off here is that each additional Git repository adds extra overhead to your development process - all Git commands and operations happen at the level of a single Git repository. On the flip side, each repository user will have an entire copy of the repository history, making very large repositories cumbersome to work with for casual contributors.

share|improve this answer
add comment

Git operates on a whole tree at once, not on just the subdirectory you're on.

Let's say you have your project at

C:\MyCode\ProjectABC

And let's say these two files have changed:

C:\MyCode\ProjectABC\stuff.txt
C:\MyCode\ProjectABC\Stuff\MoreStuff\morestuff.txt

When you're in the project root and you do a git status, you'll see these files as having changed:

stuff.txt
Stuff\MoreStuff\morestuff.txt

If you cd to the MoreStuff directory, though, will you see only the morestuff.txt file? No. You'll still see both files, relative to your position:

..\..\stuff.txt
morestuff.txt

As a result, if you lump all your projects together in one big ol' Git repository, then every time you go to check in, you'll have to pick from among changes in every project.

Now there could be ways to mitigate that; for instance, you can try to make sure you at least temporarily commit your changes before switching to work on a different project. But that's a lot of overhead that each person on your team would have to deal with, compared to simply doing it the right way: one Git repository per project.

share|improve this answer
    
Thanks for this argument, I agree ;) But most of the developers used to CVS do not agree, they want this behavior: They want that WinCVS show their changes across all projects instead of trying to remember what project they made a change (if you change several files on many directories about the same fix, you risk to forget to commit one of these files). The repo tool from AOSP allow to mix multiple Git repositories and the repo status showing changes across all the projects ;) Cheers –  olibre Nov 18 '13 at 8:30
add comment

There doesn't seem to be an argument in favor of the big repo in this thread, so here's one:

The advantage of a big repo with all your code in it, is that you have a reliable source of truth. All the state in your overarching project is represented in that repo's history. You don't have to worry about questions like "What version of libA do I need to build libB from 3 months ago?" or "Did the integration tests start failing because of Susan's change in libC or Bob's change in libD?" or "Are there any callers left for evilMethod()?" It's all in the history.

When related projects are split into separate repos, git isn't keeping track of their relationships for you. Your build system needs to know where to find the code for all its dependencies, and more importantly what version of the code to build. You can "just build everything from master", but that makes it hard to reproduce past builds, hard to make changes (or rollbacks) that need to be synced across repos, and hard to keep branches in a stable state.

So the question isn't "One big repo or many small repos?" It's actually "One big repo or many small repos with tooling." What tool are you going to use? Repo (Android) and gclient (Chromium) from Google are two examples. Git submodules is another. All of those have major downsides that you have to weigh against the downsides of a big repo.

Edit: Here are some more answers Choosing between Single or multiple projects in a git repository?

share|improve this answer
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.