[acqq]

I don't use Git and would like to know how the following problem is solved in Git.

Say you have a project which is a hundred megabytes big. And you have to develop almost in parallel three or four "generations" of the project -- let's say. v1, v2 and v3. In parallel means you'd like to be able to build any of the three versions without having to take the version out of the repository first. You can't say that v1 is obsolete, as soon as some bugs are reported in v1 you have to fix them in v1, v2 and v3. And every bigger version is "newer" but some features can be added in v2 and v3 some just in v3 etc.

How can you work on such a big project and have a single repository where all three versions are present, and work on these three versions in parallel (having sources which are compiled in different base directories)?

[beagle3]

What does "take version out of the repository first" mean?

You can do a "git checkout" to get a copy out. On a modern drive, checking out a hundred meg history takes a few seconds.

You do not need multiple copies on the disk at the same time - "git checkout v1" when you are working on v2 will do only the changes necessary to make your directory into "v1", and then you can do "git checkout v2" or "git checkout v3" to get another version.

Alternatively, you can just mount your git repo as a filesystem, e.g. https://github.com/davesque/gitfuse (there are other projects - this came up on search, never used it myself).

And anecdotally, my git repos with tens of branches tend to take much less space than one checkout. git is super efficient about storage.

[jlgreco]

Just make a branch for each v1,v2,v3. Instead of having a single main, you have three. Unless you are literally typing with both hands on two different keyboards, you just checkout whichever branch you want to work on at the moment. That is a very lightweight operation.

Note that 100MB is not really big in Git; you don't really run into issues until you are in the low GB range (at which point you should probably be considering if perhaps you actually have multiple different projects in the same repository. If so, that is where tools like 'repo' can step in: http://en.wikipedia.org/wiki/Repo_%28script%29)

[taspeotis]

> (having sources which are compiled in different base directories)

With my nascent Git understanding, I think you would just have multiple branches for v1, v2... and then clone the repository multiple times so you have multiple working copies.

Check out v1 in the first one, v2 in the second one.

Although changing between related branches is usually quite quick in Git. Also, a fresh checkout of ~100mb is not a lot. At least for an SSD.

This also relies on having a centralised Git repository for you to push/pull changes to. But I believe Git allows you to synchronise multiple repositories on disk.

You're rarely developing two things at once in any given instant of time... why not just quickly check out the branch you want?

[MBCook]

> and then clone the repository multiple times so you have multiple working copies.

This is probably not what you want. First, you should know that switching between branches in Git is insanely fast. In general, it won't get in your way.

If you clone the repository, each one is a full git repository. That means you'll triple the storage on the disk. Worse, you'll have to do 3x as many pulls to keep all 3 repositories up to date.

> You're rarely developing two things at once in any given instant of time... why not just quickly check out the branch you want?

It often comes up, but that's what we do. We may have a dozen branches on our machines (the thing(s) we're working on, recent things we worked on, the one that's been sitting for a while we're waiting on an answer to pick up again) and we can switch our project within a second or two on a simple rotating hard drive.

[taspeotis]

I know this, but GP was asking about how to do it with "different base directories" which I'm assuming is asking for an analogy to Subversion's multiple working copies (i.e. check out this location from the repository to this location on disk).

[acqq]

Yes you're right, the thing is, the project produces different binaries which should be accessible for all different versions, which was solved by having only different base directories, all the configuration files build to same subdirectories no matter which version. If I'd switch to "always having only one version in a single base directory" then I'd have to maintain different temporary output and binary output names in all the configuration files in every version which is quite ugly. Then I can't use any "known fixed subdirectory names" in the projects.

[MBCook]

A Successful Git Branching Model [1] is a very common way to deal development in a good sized project. You could consider the bug fixes to v1, v2, and v3 to be hot fixes. You could choose to keep a single running branch (the equivalent of master in the model given) for each of the older versions if you keep adding occasional features.

I know I've seen guides online of how to deal with the exact problem you're describing, but I can't remember where to find any of them right now.

[1] http://nvie.com/posts/a-successful-git-branching-model/