Comment by jdblair | Hacker News Reader

Comment by jdblair | Hacker News Reader

CVS was awful, but it was so much better than RCS, which operated only on single files. There was a time in the late 90s when CVS + Bugzilla + Tinderbox was the state of the art of CI if your toolset was all open source. I used this combination at multiple workplaces 1998-2002. It worked and we shipped, but we didn't really understand how bad the tools were.

At Sun all stuff was in Teamware, except when it wasn't, because every group at Sun could do whatever they wanted to (we used SVN in the x86 ILOM team). Teamware was good but suffered by being a wrapper on top of SCCS.

SVN was a revelation after CVS. I resisted switching to git from SVN for a long time because the mental model for SVN is so much simpler: everything is in one central place, every change is marked with a monotonically increasing version number, remember a number and you can always reproduce the state of the project. Eventually I saw the huge benefit of the "git workflow" (local branches, pull requests) for collaboration. Branches in SVN are error prone and always risked painful conflict resolution, so we made them rarely.

Perforce, which is commercial, was like stepping into another dimension (you mean all this stuff just works? Out of the box?). There's another historical timeline where Perforce has an early open-source model (like Redhat) and is the dominant VCS.

I enjoyed that remembrance of 20 years working on free-software based projects, not a bad way to start Sunday. I hope it was worth your time!

Why are branches in SVN error prone? We branch constantly and haven't had any serious problems.

I think my memory of pain is during merging. We settled on a fairly simple, conventional system: mainline new dev, branches for each release, and occasional personal branches for experimentation. This meant we rarely merged other than fixes to sustaining branches.

The branching isn't the problem, but the merging is. My experience is that it depends on how closely the team is working together. If everybody is working on separate files, then SVN can merge together on a file-level. If people are working on the same files, then every such file requires manual merging. Since git works on a line-by-line basis, merging is much easier. It still requires a human to look through the resulting merge for logical consistency, but it gets a lot closer on the first try.

We have multiple people working on the same files and use Eclipse to do line-by-line merges automatically (except when there are actually conflicts). It works fine. So I still haven't seen any real evidence of error prone merges.

If someone can come up with an error free merging for all situations, it would be the "killer app" for configuration management. I would especially look forward to merging for XML files as well.

Do any source control systems have filetype-aware merge algorithms? We can do something smarter when merging XML than textual line diffs.

Totally agree. Could AI or machine learning be used for this type of application? I don't know much about machine learning, but I could imagine that it could be used to learn the programming habits of a development team and, perhaps, use it as a context for determining its merging strategies.

Or any language grammar, in fact.

Git can be told to use custom diff and merge drivers for particular file extensions via .gitattributes: https://git-scm.com/docs/gitattributes

For example, I have used .gitattributes to make git use MS Word to merge docx files, and LabView to merge .vi files. TortoiseGit (for Windows) includes diff/merge driver scripts for use with MS Word files.

While not a source control system, the JetBrains IDEs have a very good merge tool that is filetype aware. For example, WebStorm/IntelliJ Ultimate, when merging JavaScript, often has a "magic wand" option that can detect when merge conflicts are actually resolvable if you parse both sides first, and merge the AST.

It doesn't always work quite right, but it's good enough that I use it quite often.

Plastic SCM claims to have C#, Java, C and VB.net semantic diff. Looks pretty impressive - sad that it's proprietary!

https://www.plasticscm.com/features/semantic-version-control...

My experiments showed that you can get good character-based diffs from using a syntax highlighting tokenizer. [1] It was faster than a pure character diff algorithm, but the resulting diffs/patches are interoperable, and provided quite reasonably semantic diffs on the examples I tested. Most tokenizers are great too because they tend to operate very well with work-in-progress code or broken/edge-case code (because they are the same sorts of tools we use in our editors).

I've not seen someone actually use it for source control, but the core idea is simple enough for the taking.

[1] https://github.com/WorldMaker/tokdiff

You're never going to avoid all errors, but with additional tools SVN merging seems no more error prone than Git.

I do agree that source code control needs to move beyond lines to deal directly with nodes in a tree structure. That could be XML, JSON, a C++ parsed abstract syntax tree, etc.

So I've actually thought about this a fair bit recently, since I'm making some changes to C++ code that touch a lot of files in reasonably straightforward ways. The changes should be possible to merge conflict-free in basically 100% of cases, but since so many lines are touched, no VCS merge tool can manage it. Most of my changes are just typenames, so I figured, you could do some sort of AST-based merge to allow those changes to merge with semantic changes to the surrounding code.

But this has a lot of problems. Namely - most of the time, when two people change the same line, the changes really do conflict, and someone really does need to manually merge them. In fact, sometimes even when your VCS merges things happily, it still gets them wrong because two changes conflict semantically but don't touch the same lines.

So I guess I would say, I think merging is an impossible problem to 'solve', and going to a more granular merge strategy is actually a move in the wrong direction. You could maybe fix my particular case by 'whitelisting' those typename changes, and saying 'these are allowed to merge with anything else', but at that point... the effort required to specify that unambiguously and make it work properly is probably higher than just merging the changes.

IIRC SVN merges only created conflicts if the same lines were changed. If I edited line 10 and another developer edited line 200 there was no problem. It's been a while, but I also never encountered any serious issues with branching and merging in SVN.

As others have mentioned, the problem with branches in SVN isn't the branching, it's the merging. IIRC, this was because SVN didn't track merges, so if for instance you have a "stable fixes for release X" branch which is repeatedly merged into the trunk, you'd soon encounter wonky behavior.

Subversion absolutely tracks merges, but you don't really need that just to keep a stable branch regularly updated. That's a very normal and expected use of a branch and should not give you "wonky behavior" in neither git nor svn. Thousands of projects do it every day. Any encountered problems are likely not inherent to your version control system.

It definitely didn't use to track merges. That got added after most people jumped ship to git. Before that, you had to specify the common ancestor commit of the things you were merging, which you usually didnt know and had to dig around in slow logs to find out.

It has tracked merges longer than github has existed, just to keep things in perspective. But, again, it's not required just to keep stable branches around since commit numbering is linear in svn. It's very convenient for anything less trivial than that though.

I still don’t like the Perforce model of workspaces or whatever they call it (clients?). That mapping between the server folders and your local ones. Extra complexity for no obvious benefit I could see.

The complexity is completely optional. Your client map can just map the entire depot to a single directory. And it has always been very easy to enforce this at the organizational level, with a small script in the server.

For the right use case workspaces are awesome.

We used to do code + art in the same 1TB perforce repo back when I did gamedev. Art folder was ~600GB. Having a workspace to eliminate that as a developer was awesome.

Git still fails to even approach the usefulness that P4 brought to those types of shops. Between the auto-cache proxies, dealing with 1TB+ repos and workspaces there's a reason P4 still does pretty well.

I won't reply to all the comments saying mostly the same thing, but Git doesn't have this, true. SVN, another centralized system, does have it. Shallow checkouts plus folder checkouts and you can have any combo you want. Without adding another concept to take care of.

Much simpler conceptually, in my opinion.

It allows you to check out small bits of a really large repo.

It was great for large projects. I worked on a project that was similar to Android. Imagine 10 device trees (device drivers), two OS trees (Linux, vxWorks), and two application trees (the old stuff, the new stuff). You could define a mapping that got you just the trees you needed, which both sped up builds and VC operations (although p4's local indexing made most VC operations lightning fast).

Imagine a world where 'svn up' or 'cvs up' takes 20 minutes. Not only did the client mappings limit the scope of the operations, but local indexing brought the time for those operations down to 0-4 seconds.

Yeah, the mapping was a wart. Piper+CitC is much nicer, it's a file system that pretends you have the whole tree locally, while actually storing only the stuff you changed.

Rule of thumb, one man's useless version control feature is another man's saving grace. I've never needed to open multiple changelists simultaneously in one work area, but I'm sure someone loves that feature.

I use RCS for version controlling single in a bunch of places. Using Emacs' VC mode makes it mostly invisible to me.

Reply on news.ycombinator.com