SCC Role Call

[hooovahh]

35 minutes ago, smithd said:

They go on vacation and everything is locked, as an example.

Great example and one I've forgotten about.  So you have a couple of options (all of which sound like git to me anyway).  You can start editing the code anyway even though you don't have the lock, and send that person an email saying you are editing some code they have locked.  When they get in they will either say "Oh yeah sorry I didn't make any changes" to which you commit yours over theirs (breaking the lock), or they say they have made changes to which you'd need to merge the changes just like a git commit when you both made changes at the same time (am I wrong?).  Or you can steal the lock while they are on vacation and force them to have the conversation with you when they get in and try to commit, at which point they again will either say they had pending changes, and a merge needs to happen, or they don't.  Isn't it still just like git in that if only changes happen in one place at a time, that is what gets committed, and if there are multiple changes at once time, a merge needs to happen?

Again I want to make it clear I don't use git, so my understanding might be incorrect but from an outsider I didn't see that as a compelling reason to change.

[smithd]

Sounds basically right, any file that was changed by two people simultaneously will need some kind of merge. In git its the responsibility of the person currently trying to commit.

First they must pull the branch they want to commit to into their own to make sure they have a matching tree. That is, if master has commit 1,2,3 and your local copy only has 1,2 and then you committed 4, then you have to pull commit 3 into your repository so the trees match.If there are no files changed in 3 that you changed in 4 the merge happens seamlessly and then you commit your changes to the centralized repository so now you and the central repo have 1,2,3,4. If 3 changes file A and 4 changes file A then there is a conflict and you (developer of 4) must resolve it before pushing 1,2,3,4 and potentially 5 to the server. Its definitely a more complicated series of steps than you would usually have to deal with in SVN because of the locking, but its similar in the conflict scenario. Its also the way all merging works, so once you know how to do it between your copy and a master repository, you can do it with branches on your own machine or with others' forks or whatever without much if any additional learning.

 

The other thing I've been looking in to lately is git subtrees/submodules. They let you embed a repo in another one, so for example if you have a common library in your organization you could (instead of distributing as a package) distribute just as source embedded in the repositories it depends on. Git keeps track of what is what and if you make a change in the subtree it can be pushed back up to the main repo. That is if I have shared library A and consuming projects B, I could make bug fixes for A and push them back up to A without ever leaving the project I'm currently working on B. I haven't used it yet but it seems like an interesting tool for a category of shared tools. Obviously if the shared code is super stable there isn't much value, but... Has any git user tried this out, or does Hg/svn have similar functionality?

[Antoine Chalons]

It took me about 5 years (from 2006 to 2011) to convince people at my company to use a SCC, we use SVN + TSVN, we set up a ColabNet Subversion Edge (free) for local hosting.

For small projects (not professional) I use Git + GitHub because I wanted to try it out, maybe one day I'll tell my colleagues about it...

[LogMAN]

5 hours ago, smithd said:

Has any git user tried this out, or does Hg/svn have similar functionality?

Yes, I tried sub-modules and decided against them. Not sure about Hg or SVN

The obvious reason to use sub-modules is to maintain some "common" repository for use in multiple projects. The OpenG libraries are a perfect example of such libraries. Unfortunately there are a some things which made them less useful to me than first thought:

1. Folder hierarchy

Each of those libraries are organized in their own hierarchy of folders, most of which you don't need in your current project. In my case everything is organized in LabVIEW projects using virtual folders where the actual hierarchy on disk is much less complex (typically one folder for each library). So, when reusing a library it would be great to get the same hierarchy in the "owning" project in order to maintain consistency. Since my reuse libraries are organized without library files (*.lvlib), they are just a bunch of VIs on disk, which makes them hard to import into each project because I would have to recreate the hierarchy over and over again. VI packages solve this problem elegantly in my case.

2. Palettes

Reusable libraries commonly provide a bunch of VIs, most of which you don't (or shouldn't) use in the owning project. One great example is the array manipulation palette of the OpenG libraries which contains a lot of instances for few polymorphic VIs.

Being able to select between a few polymorphic VIs on a palette is way easier than searching through the project to find the appropriate VI. For QuickDrop users like me the search function is very useful. By having all polymorphic instances in the project the search results are useless as all instances are returned as results (depending on the naming schema). Without palettes everyone is forced to search through the project, which is very time consuming.

3. Maintenance

The ability to change code "on the fly". You can fix bugs during development of your own project and therefore improve multiple projects at once. While this is true there is also a great chance to break consistency between projects because someone decided to do an "improvement" that is incompatible to other projects. This is actually my main reason against sub-modules.

Example: Add VIs from a sub-module to a library file in the owning project, push the sub-module, pull it into another project, welcome to coding hell.

4. Independence:

By splitting reuse libraries into separate repositories and providing them as packages you gain control over each one of those libraries individually. During development of those libraries you can focus on the tasks it is supposed to do instead of having to consider the "big picture". In my experience this is a big burden taken from the shoulders of each developer. I already have to consider about 1k+ VIs in a single project while I don't have to consider the 1.5k+ VIs in our reuse libraries. And these are just "tiny" projects compared to the ones I have seen others do. When one of our reuse libraries is missing a feature I do a feature request. When something is not working as expected I do a bug report. Both of which can be implemented and analyzed on their own pace. If I need them done "now", I'll take charge of the feature request or bug report myself.

Of course these are just my experiences based on our workflow. It could be an entirely different case for you.

[smithd]

5 hours ago, LogMAN said:

Yes, I tried sub-modules and decided against them. Not sure about Hg or SVN

.....

Of course these are just my experiences based on our workflow. It could be an entirely different case for you.

It sounds like your first comments are on organization which I get. When it comes to developing our current common library + mid-level dependencies I found that I very often would add things and forget to set up the palette correctly, so I kind of got use to plumbing the depths of vi.lib to find the files I needed...but yeah, not ideal for someone approaching it for the first time.

Maintenance I'm less concerned about. I think submodules are a bit different than subtrees here, but with subtrees you have to tell git what it links to, so its actually possible for the code owner or project lead to have their git instance "know" about the subtrees while for everyone else they just show up as sections of the same repo. Then if something needs to be merged to the main repo its a bit more controlled -- you sort of have to know what you're doing.

The other pros I can see are:

• Its a lot easier to do continuous integration work when you don't have to deal with vipm and instead everything is all right there in one neat package ready to build
• it lets you work with different versions of the common library more easily, for example still being able to deploy dependencies of v1.1 while working on v1.2

Edited June 13, 2017 by smithd