Reputation
8,955
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
4 27 50
Newest
 Good Answer
Impact
~663k people reached

Jun
19
comment In git, how to do versioning for a dozen libraries all worked at in parallel
Reviews are very important to us. That's one of the reasons we're concerned about an issue (and its reviews) being split across several reviews for several changes in several repositories. Plus we don't want to get bogged down in administrating us to death over one issue is that we'd rather spend the time writing and reviewing code. Re submodules: so far, the only thing I have heard about them is "don't bother, this isn't the git way". Well, given that our requirements seem to be so unique, maybe we should revisit this decision...
Jun
19
comment In git, how to do versioning for a dozen libraries all worked at in parallel
Well, currently most of us are not comfortable. :-/ What's more, even those who are (and who pushed for the move to git), do not know how to make our development process fit with git. Sigh. It's going to be a few tough months, I'm afraid, until things start to become smoother. Thanks anyway, yours is the most/only helpful answer so far.
Jun
19
comment In git, how to do versioning for a dozen libraries all worked at in parallel
You describe how to solve the dependency problem (which, as I have said before, we have sorted out) and negate the very problem we are having. Why do you even bother? (FWIW, we write software that drives power plants. Clean, secure, and thoroughly reviewed code is a prime feature.)
Jun
19
comment In git, how to do versioning for a dozen libraries all worked at in parallel
Thanks, but here issues are usually kept small and mostly only one (or rarely two) developers work on one feature.
Jun
19
comment In git, how to do versioning for a dozen libraries all worked at in parallel
So this requires someone creating a feature branch for one library to also merge all the others when merging or rebasing. This is a real drawback. (BTW, SVN also only ever does lazy copies.)
Jun
19
comment In git, how to do versioning for a dozen libraries all worked at in parallel
Thanks, we are indeed currently looking at this. What I do not understand in the light of this is how we'd do branching with git. In SVN, branchings means copying a subtree (in the repository) to somewhere else (in the repository). With this, it is easy to create branches of any subtree in your repo, so if you have many projects in there, you can branch off each of them individually. Is there something like this in git, or would we always only be able to branch a whole repo?
Jun
18
comment In git, how to do versioning for a dozen libraries all worked at in parallel
A careful read of my question should have shown you that we have problems with the overhead involved in propagating changes between repositories. This has nothing to do with your answer.
Jun
18
comment In git, how to do versioning for a dozen libraries all worked at in parallel
Could you please elaborate? I am not sure what you are suggesting.
Jun
16
comment In git, how to do versioning for a dozen libraries all worked at in parallel
@arnaud: Maven is something in the Java world, while we're in C++ land. (I'm not saying it wouldn't work for us, only that we don't know it.)
Jun
16
comment In git, how to do versioning for a dozen libraries all worked at in parallel
@arnaud: The turnaround times for such a process for (currently rather common) changes cutting through three or more layers would kill us. I thought my question described that.
Jun
16
awarded  Good Answer
Jun
15
awarded  Promoter
Jun
11
comment In git, how to do versioning for a dozen libraries all worked at in parallel
@Winston: I do not insist at all. See this comment. Thank you very much for the headsup, though, I will make sure to make our team aware that not everyone believes in the multiple repository approach.
Jun
10
comment In git, how to do versioning for a dozen libraries all worked at in parallel
Again, declaring dependencies is not our problem. We can do this already. The problem is how to manage changes cutting across several projects/libraries in an efficient manner. Your answer fails to explain this.
Jun
10
comment In git, how to do versioning for a dozen libraries all worked at in parallel
But dependency management is not our problem, this is solved. We currently regularly make changes across many libraries and need to minimize the overhead of creating new versions while maintaining stable project releases. Your answer doesn't seem to provide a solution to this.
Jun
10
comment In git, how to do versioning for a dozen libraries all worked at in parallel
@Daenyth: Should I be eager to chase after the bone you threw me? You might just as well tell me to look at the moon. Sigh. Why do you think semantic versioning is relevant here and how do you think we should employ it to solve the problems I have described? (FWIW, we do use semantic versioning for our stuff. But that we know by looking at a library's version number whether it might be incompatible doesn't seem to help at all here.)
Jun
10
comment In git, how to do versioning for a dozen libraries all worked at in parallel
@Ixrec: Integrating more hardware is similar to porting code to more platforms: the more you have done this, the less you need to change for yet another hardware/platform. So in the long run, the code will stabilize. However, right now we will need to find a process that allows us to stay in the market long enough to get there.
Jun
10
comment In git, how to do versioning for a dozen libraries all worked at in parallel
@Ixrec: I was told that "this is not the git way" of doing things. Everybody uses individual repositories for individual projects, so it was decided we do that, too.
Jun
10
comment In git, how to do versioning for a dozen libraries all worked at in parallel
@Ixrec: From the question: "Almost each time we integrate some other vendor's hardware we run into cases our current interfaces did not anticipate, and so have to refine them." And what you describe is doing versioning in the code. However, this is what SCM was invented for.
Jun
10
comment In git, how to do versioning for a dozen libraries all worked at in parallel
@Bart: It's not just the tool changing, we are also in the process of moving more code into libraries, which makes this problem more obvious. However, in SVN, everything was in one repository. So you could merge everything into the trunk in one big merge operation. The third issue: I have worked with SVN for many years, and know the best practices there. I am, however, new to git, and don't know how to tackle these problem with it.