Reputation
8,696
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
4 25 49
Newest
 Informed
Impact
~565k people reached

Jun
25
comment In git, how to do versioning for a dozen libraries all worked at in parallel
@Patrick: And again no argument on the subject. HAND.
Jun
24
comment C++ is easy once you know PHP
"When you consider that PHP itself is written in C" ...then what? Most code is either written in C or compiled/interpreted by something written in C while running on something written in C. So? Does that mean that all code has some magical relationship with C? This is a bullshit argument. Oh, yeah, and it's true: writing your own sort algorithm in C++ today is stupid. But thinking that, coming from PHP, you could jump right into C++ and produce anything but horrible code is just as stupid. (FWIW, I have taught C++ to Java developers for several years. The code they produce at first is evil.)
Jun
23
comment In git, how to do versioning for a dozen libraries all worked at in parallel
P.S.: " I'd imagine you hardly want to switch languages." This is embedded stuff. :)
Jun
23
comment In git, how to do versioning for a dozen libraries all worked at in parallel
We are now evaluating putting the libraries into only two repositories. That's still more than one, but much less than "one for every project", and the libraries can very well be split into two groups. Thanks for your input!
Jun
23
comment In git, how to do versioning for a dozen libraries all worked at in parallel
@Patrick: I have described the steps in my question, and not only is the turnaround non-zero, it's also rather big. You, OTOH, haven't even bothered to provide an argument for why that seems neglectable to you.
Jun
23
comment In git, how to do versioning for a dozen libraries all worked at in parallel
I got a bit caught up in the last few days, so now my time for the bounty nearly ran out. I gave it to you because yours was closest to a helpful answer I got.
Jun
22
comment In git, how to do versioning for a dozen libraries all worked at in parallel
"it counts as a process failure if you have to change all 4 together". Actually it wouldn't. In fact, this is exactly what we did using SVN.
Jun
19
comment In git, how to do versioning for a dozen libraries all worked at in parallel
No, backwards compatibility is ensured through release branches and is not our problem. The problem is that we sit on a currently rapidly changing codebase, which wet want to separate into libraries now, despite the fact that the interfaces are still in the phase where they change often. I know how to manage such beasts in SVN, but do not know how to do that in git without being drowned in administration.
Jun
19
comment In git, how to do versioning for a dozen libraries all worked at in parallel
I'm now on the train, having promised my oldest I'd take her to Jurassic World. Some other time?
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
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.