Reputation: 1545
I have several libraries, libA, libB, libC. Each of them is a diferent project in subversion with the structure:
libA doesn't depend on anyone, libB depends on libA, and libC depends on libB and libA.
I have a project MyProject that depends on the 3 libraries. When I make a tag in MyProject, I want to be able in the future to checkout that tag and compile it and use it. The thing is, if the tag version of MyProject compiles against the trunk of the 3 libraries, they may change, and it can happen that when I checkout the tag, it may not compile, or work diferent. In order to work the same way as it did when I made the tag, I should checkout the libraries to the proper version (that I should look up repos by repos which version that is).
The current solution I have is, make a tag of every library, and compile the tag of MyProject against the tags. In subversion a tag is just a copy, so whenever I checkout a MyProject tag, it points to the tags that are already there. The problem is that over time, then number of tags increases, and although the repos size doesn't increase, it does the in the disk.
Now I want to migrate to git. Git tags are not a copy, so I have my original problem. If I go to a tag version of MyProject, the other libraries may have changed, so I should change the version of the other libraries.
How do I solve this problem?
Upvotes: 0
Views: 49
Reputation: 5477
One solution is to denote what tags of the other libraries you need to compile with. Another solution for your problem that I would suggest is using git subtree merging so that you can embed the appropriate version of your other libraries into your version that you are building. In this scenario each library gets its own repository. You then have one additional repository that integrates the different libraries together.
It really will come down to the way in which you work on these libraries and how independent they need to be from one another.
In short, don't compile against the 'trunk' of the other libraries, manage them and mark them with a tag when you compile so you can recompile old combinations versions later. (This is often important for regression testing.)
Saying that git tags aren't 'copies' while true isn't exactly an advancing statement either. Git tags are just like branches except they don't move. They are pointers to a given commit. This is exactly the kind of thing they are well suited for. You put an identical tag on all of the these libraries so that you can check out the exact combination used to produce a given build.
The main issue I see is that you have yet to wrap your head around how git works. Trunk/branch/tag distinctions are useless because they are managed properly natively as oppposed to how svn manipulates them.
I would really strongly suggest you take a read through the git book to learn How to use git, instead of seeing it as what step do I take to do x? http://git-scm.com/book
Lastly tagging or not tagging it on either SVN or GIT isn't going to increase your file size, the systems are aware that the code is common and duplicate.
Upvotes: 0