loading

How do you manage multi-platform software projects?

Currently I am coding a project which uses an attiny2123 and a computer side client. Currently the firmware and client projects reside in their own (one for each) SVN repositories. When I release it (it will be open source) what is the best way of linking/managing the two linked projects? Should they both be dropped into the same SVN repo with different source trees? or kept seperate? or something else?

Thanks in advance,
Drew

sort by: active | newest | oldest
orksecurity6 years ago
Uhm... That one's something of a micromanagement point, really. There's very little difference, from the user's point of view, between two SVN servers and one with two project directories ... or even one project with two subdirectory trees. Keeping things on one machine is a bit easier to back up and ensure that you've got a consistent snapshot of the two projects, and may be a bit less work for whoever's running your servers, so it may have a slight edge. But if this is what you're spending your time worrying about, either the project is going amazingly well or you need to take another look at your priorities.

Sorry ork, I don't want to be contentious, but I program for a living and couldn't make heads or tails of what you just wrote. "micromanagement"?
Micromanagement: Akin to misdirected micro-optimization. Attention to a detail which really won't make enough difference to justify that attention. Unless the rest of the project is running amazingly well, this is not something worth spending a lot of time on, because it honestly won't make a great deal of difference. Pick something you're comfortable with and move on to more important issues.

Given a choice, making sure they all get backed up together is a Good Thing. Outside of that... well, assuming you write batchfiles or set up Eclipse projects or otherwise semi-automate your repository management, this is something you really only have to look at once.
idk. my last employer required distinct repos for each and every version, whether that was PC OS based (wintel, Mac, etc.) or embedded vs desktop.

It wasn't a matter of micromanagement, which is generally defined as form of over-management distinguished by the nitpicking of managers to minutiae, it was a matter of version control for each distinct product to maintain a line of support unique to each end-use software item.

I wasn't a fan at first, but over time I grew to understand the reasoning behind it, since you can release updates to one without affecting the other.
That's what branches and tags are for... and if you use those features of your version control system, it takes less storage because the files which haven't yet diverged can be shared.

CVS, SCCS, and SVN all have that capability. I'm not sure whether CMVC does, but I believe so. I haven't use RTC's code repository features yet, but I'd be shocked if it doesn't support branches and tags.

If your system _doesn't_, then replicating the directory makes more sense.
My understanding is that branches are for different versions of the same code, not for code that belongs on distinctly different hardware, ie, embedded code for an ATTiny vs a desktop application used to interface with the embedded hardware.
Agreed. For that, you want either different projects, or different directories within a single project, depending on how you want to manage things. If different projects, it is most convenient (and easiest to back up) if they're all on the same server, but they don't absolutely have to be.

I'm working on a system which involves lower-level code kept in one repository and application code kept in another repository, with a project we depend on being brought in from a third repository... and, oh yeah, the different-platform version kept on yet ANOTHER repository. And of those four, three are completely different source code control systems. I certainly don't recommend this if you can possibly avoid it, but it usually doesn't interfere with getting productive work done, especially since two of them have Eclipse clients and thus look more-or-less the same to the user once they're configured.
And that is exactly what the OP is asking about.

"I am coding a project which uses an attiny2123 and a computer side client. "

Hence,

1 embedded app
1 desktop HMI app

I understand where you're coming from with respect to desktop apps and agree in that case to some degree
Agreed.... but that takes me back to my original point. Whether this is one project with two directories, one repository with two projects, or two repositories really doesn't make all that much difference. That's roughly my order of preference, but if you're already set up on two repositories I would recommend not reorganizing unless you are at a point where the project is otherwise under absolutely no time pressure.
andy (author)  orksecurity6 years ago
Hi,

Thanks peoples, that was informative. From a perspective of not knowing I couldn't really tell whether it was important or not.

I thought it worth asking because generally I find people in software development get really wound up about things like this, although I really can't work out why. Even broad sweeping technical arguments like "it is/isn't important" , "this thing is/isn't a good solution" and so on leaves even some of my mild mannered colleagues foaming at the mouth.

@orksecurity - the project is under literally no time pressure at all (it's a spare time project with absolutely no time constraints, save perhaps my attention span and lack of immortality), but as you say there is little reason for switching methods so I'll leave it as is. It's not so much that I am spending my time worrying about this, more that I thought asking might resolve whether it was important or not. It immediately sprung to mind when asking this question that one could make many arguments and counter-arguments for each method, but whether any of them (or something I hadn't thought of) were important was what I was struggling with.

Thanks for your time,
Drew


"If this is what you're spending your time worrying about, either the project is going amazingly well or you need to take another look at your priorities. " Ooh, well aren't we just the hoity-toity software god?
Chalk it up to envy. That's my profession, and I meant it quite seriously: this is a difference that makes almost no difference, so if someone can afford to worry about it they've got other things under control to a remarkable degree.
:-) You are, of course, quite right, actually. Except that I'm sure we've both had the experience of people (especially in meetings!) spending far too many hours arguing about how to implement some pointless little function, while the bigger picture just goes all to pot.

Consider the "You should use a different size font for your histogram labels" during an internal review of somebody's talk :-(
kelseymh6 years ago
I would definitely keep them in a single repository, with separate packages (what you call "source trees"). Pointing to separate repositories is just a stupid pain in the...er...carpal tunnel :-)

Since the firmware and client are entirely separate builds, you are not really doing a "multi-platform software project." One of the collaborations I'm currently in (GEANT4) distributes code for Linux, Mac, Windows, and various proprietary Unices. There is one single repository, and the Makefiles have all kinds of platform-specific switches (okay, actually that's all handled in architecture.gmk).
seandogue6 years ago
Tough call. I'd suggest that you ask in the various code forums on IRC, since there are a lot of hard hitters there.

My own opinion? two separate repositories with links to each other.

My logic? they're different codebases...therefore, different repos.