Y'all see this yet?

[Stobber]

http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/#

 

He calls forward lots of niggling doubts that I've deliberately squelched over the last few years, but I can easily recall a time when trying to learn gitflow that I paused and asked myself, "Is SVN really so bad that I'm spending my evenings trying to do this instead?"

[Yair]

We use SVN (and people have a hard enough time with that when there are conflicts or when a commit or update fails and you sometimes have to do various combos of manual and automatic cleanups to get back to a working state), so I wouldn't know.

 

The main feature I would want from the DVCS world is the ability to have local versions which allow you to do convenient testing of features and I can generally manage that in the cases I actually need it with a bunch of annoying methods (branch, create a manual copy, commit and revert if needed, etc.). That doesn't give me enough of an incentive to want to transition to DVCS, so in my case the answer is "No, SVN is not so bad".

[hooovahh]

I quite like SVN.  Yeah I know there are times when it has problems and you need to do some manual fixing, but those are generally times when I screwed up.  So I just try to not do what I just did again.  The problem comes when every person using SVN needs to learn those lessons one at a time.  You can say "Don't create orphan locks" but until you learn it and fight to fix some SVN screw up you won't remember it.  I could probably get used to some other SCC but it does what I need.

[ShaunR]

Interesting post. Kudos.
 

And then Git happened. Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website. It’s so transparent that developers routinely tell me that the easiest way to learn Git is to start with its file formats and work up to the commands. And yet, when someone dares to say that Git is harder than other SCMs, they inevitably get yelled at, in what I can only assume is a combination of Stockholm syndrome and groupthink run amok by overdosing on five-hour energy buckets.

 
That is the required personality type for Linux developers who are the ones that tend to write this stuff.
 
I've got all the various different version control systems. They confuse the hell out of me and I'm never really sure if I have committed to my local or the central repo. Even in light of my ignorance. None really work for LabVIEW (see the part where he talks about blobs). They all get demoted to back up systems and there isn't much point in backing up to your own PC.
 
The only issue I have with SVN is the singular history. That is solved exactly the same way as he describes for distributed - break into smaller repos. If you have repos for each sub module/component/sub project then that also becomes atomic work packages which now work properly if you separate source from binary code.
 
Long story short. not so long. I still use SVN and it looks like I've used it so long it's coming back in fashion again

 

PS.

Well worth expanding the superscripts inline

Edited March 4, 2015 by ShaunR

[odoylerules]

He makes some good points but i would guarantee that there are a hundred articles out there that would argue against every point he makes much better than i could.  I would say people just need to work with whats best for them.  

 

I use GIT and i'm sticking with it.  The ease of branching is what made me switch from SVN.  Making a branch, testing a change and merging it back in is fast and easy. 

 

I will say i do miss the locking aspect of SVN, especially since labview like to randomly touch files in the project.  

[drjdpowell]

I like Mercurial much better than SVN.  Or rather, I like “TortoiseHg Workbenchâ€.  But I've not really used either much more than as a backup system.

[Stobber]

I use GIT and i'm sticking with it.  The ease of branching is what made me switch from SVN.  Making a branch, testing a change and merging it back in is fast and easy. 

 

If you're the only developer, sure. But merging changes to any of the impure XML files NI uses (.lvclass, .lvlib, .lvproj) or to the same VI is basically impossible. I've always ended up just stomping on one developer's changes instead of trying to merge them.

[ThomasGutzler]

He, who manually merges conflicted .lvclass, lvlib or .lvproj files - successfully! - shall be my overlord.

How many times have I considered changing mime-type of those beasts to binary just to avoid the pain that inevitably comes with a (what svn thinks was a) successful, automatic merge of them.

[Stobber]

He, who manually merges conflicted .lvclass, lvlib or .lvproj files - successfully! - shall be my overlord.

How many times have I considered changing mime-type of those beasts to binary just to avoid the pain that inevitably comes with a (what svn thinks was a) successful, automatic merge of them.

 

I do mark them binary in my repos. You can't even manually merge most changes because there are interrelated tags and mystery hashes designed into those file types. They aren't "pure" XML.

[mje]

We've stuck with SVN, it's suited me just fine and I love it. At one point I understood the DVCS systems, but never saw the need for it in my workflow and haven't bothered to switch over. Because all the cool kids are doing it doesn't fly for me.

 

Now excuse me while I cry, because my SVN is being pried from my hands in favor of...urgh. Don't make me say it. Rational Team Concert. It sort of works, so there's that.

[Aristos Queue]

For what it is worth, I can't use Git. Even for simple submits, I do it infrequently enough that I pretty much always screw it up. I've thrown away changes I wanted to keep. I've merged branches the wrong way. At this point, I use Git by writing what I want in English and emailing a friend for the commands to do it.

I recognize its power. I recognize that it is the only SCC system with certain key features. I would still rather use anything else.

[ShaunR]

For what it is worth, I can't use Git. Even for simple submits, I do it infrequently enough that I pretty much always screw it up. I've thrown away changes I wanted to keep. I've merged branches the wrong way. At this point, I use Git by writing what I want in English and emailing a friend for the commands to do it.

I recognize its power. I recognize that it is the only SCC system with certain key features. I would still rather use anything else.

 

Great to hear you are looking into one that works for us poor, long suffering, LabVIEW devs

(I'm just going to start a self fulfilling rumour)

Edited March 5, 2015 by ShaunR

[Aristos Queue]

I have thought about KickStarting a mechanical Turk type project to have the community pay the salary of a guy whose job is to be the AI to create Git commands in response to English emails.

[ShaunR]

I have thought about KickStarting a mechanical Turk type project to have the community pay the salary of a guy whose job is to be the AI to create Git commands in response to English emails.

 

You mean like emailing [a patch] to a user group? You should be in sales

Edited March 5, 2015 by ShaunR

[smithd]

I think git the command line is pretty unusable but I've found sourcetree to be the correct subset of functionality to do everything that I want. I don't particularly care for the lets-fork-everything style, so we basically use git as a non-distributed system. The easy renaming of files, lack of locks, and the ability to instantly create a local repository are all excellent. And, as the article said, a lot of people use git because of github. Thats fine too. All told I find it to be just a lot simpler to work with than perforce or tfs (I haven't used TSVN in ages).

[Aristos Queue]

You mean like emailing [a patch] to a user group? You should be in sales

I honestly have no idea what this comment means. Explain?

[Tim_S]

I miss SVN. Unfortunately, after two years of our IT person (note the singular) trying to get the old SVN server to work with our new network (new parent company) when he could, it became apparent it wasn't going to happen and I needed something file based (due to network permissions and said IT person's time). So I've been using (or perhaps misusing) Mercurial since. I admit that I do like the Hg Workbench.

[ShaunR]

I honestly have no idea what this comment means. Explain?

Sure.

 

Go back about 20 years and you would send an email to a guy/gril ( in plain English or whatever language, who you didn't have to pay) and they would incorporate your patch, or idea into the software. You didn't even need the commands. You can still do this with mailing lists today for some projects.

 

I suggested you should be in sales because only a salesman would effervesce that such a backward step would be a positive.

Edited March 10, 2015 by ShaunR

[Aristos Queue]

I suggested you should be in sales because only a salesman would effervesce that such a backward step would be a positive.

I figured it was an insult of some sort, but I was sort of holding out hope. You either a) didn't understand what I was proposing or b) did understand and decided to be insulting about it anyway. Either way, your comment isn't relevant to what I was proposing.

[joerghampel]

I used to work with subversion before I started programming in LabVIEW, and it worked very well for me. With LabVIEW, we did and still do a lot of off-line, on-site work together with our customers, and I tried to introduce them to subversion. However, we never managed to get our customers to accept it. Many of them couldn't even get around the point that there are a lot of hidden .svn folders, and there was a lot of export/import activities, so we finally abandoned it.

 

Recently, we started using git (hosted on gitlab.com), and together with the Tower GUI (www.git-tower.com) it does really work like a charm for us. Agreed, merging still doesn't work the way one would expect (or hope), but that was no more or less true for subversion, at least for me. Installation at the customer site (SourceTree) is also a big pita, but it's doable.

 

On a sidenote, Gitlab offers some additional benefits for me:

- Integrated issue tracker & API access: I created a Dokuwiki plugin that shows certain issues within a customers' namespace in our Dokuwiki which makes issue tracking much more usable for my customers

- Release management & API access: I created another Dokuwiki plugin that shows the available tags (and related download packages on our webserver), again within a customers' namespace in Dokuwiki, which standardizes and automates software releases and makes it quite easy for my customers to find the latest version

- Continuous Integration: Gitlab commit hooks trigger a Jenkins server to execute build specifications

 

All of those things are most certainly available for any given (D)VCS, and/or can be achieved in other ways. Still: For us it's a nice package.

[ShaunR]

I figured it was an insult of some sort, but I was sort of holding out hope. You either a) didn't understand what I was proposing or b) did understand and decided to be insulting about it anyway. Either way, your comment isn't relevant to what I was proposing.

 

::facepalm:: "You can't debate satire. Either you get it or you don't". - Michael Moore