Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Phml

Revision control and the Internet

Recommended Posts

So I've heard about revision control, version control, source control or whatever is the correct name, fiddled with it a few times for various reasons, but there's one thing I don't understand.

Why are people so angry about it?

Looking up source control questions brings up a barrage of hostility targeted at... I'm not sure who, actually. People who know anything on the topic just seem to be angry in general in their replies.

Even guides supposedly targeted at beginners tend to open up telling you you're a waste of oxygen who should be put on the cross if you're not using version control already. Chicken and egg, anyone?

Now, the only other time I've experienced this kind of dumbfounding aggressiveness is with Linux; and there, I think I get the point, the whole openness thing, coupled with Windows and to a lesser extent Mac being competitors.

But with version control, who's the "enemy" exactly? It just seems like a tool you either use or don't. The only thing I could think of would be, perhaps professionals have to interact with other programmers who don't use source control, which might make their projects harder to manage, which might frustrate them? Making the enemy anyone who doesn't use source control; but again, it wouldn't quite explain why people are so aggressive when others come to them to learn to use source control.

Share this post


Link to post

I've not seen much hostility against using version control vs not using any at all (in the latter case, you're simply not considered "interesting" enough), but there are pretty obvious Holy Wars over which version control system you should use. By all means, don't tell anyone you're using CVS (though I've yet to see a convincing argument against it, or an obvious drawback).

My opinion? There's something fishy about ANY version control system that you need to re-educate yourself for an entire day to even grasp the basics of its functioning (GIT, I'm looking at you), or where for whatever reason you're not allowed to use labels/tags (SVN...). There, flame away.

Share this post


Link to post

People all up in arms about version control? What a world!

I use Git at work, mostly because it doesn't have to be connected to the Internet at all to use it.

I have used SVN and CVS (ugh) in the past, but other than the hatred for CVS, and rightfully so! It sucks, mostly because it feels antiquated, but it's supported well, so whatever. I haven't seen anyone getting terribly angry at it.

Share this post


Link to post

Haha, yeah, you're probably right about people being too aggressive about this sort of thing.

But beneath the hostility there is an important message. It's a good practise to always use version control if you're working on a project - even if it's a small project and even if you're the only contributor. When I first started using CVS years ago, I found that it helped give some needed structure to my work: instead of just editing random files and copying them around, you have to carefully construct and explain each change. That's as important for you as it is for anyone else who might be looking at your work.

There are of course several other important reasons why you should do it: having the ability to "back up" your code to a remote repository and giving others the ability to follow your changes and contribute are also really useful. But for me, it was the discipline and structure it brought to my work that was the most important.

Historically, some of the older systems have been pretty terrible. CVS used to be the dominant system for years in spite of being (frankly) awful. The big change over the past few years has been the introduction of distributed systems (DVCSes) like Git and Mercurial, which have left older systems like CVS and Subversion in the dust. I'd recommend just starting with one of those nowadays, they make things much simpler overall.

Share this post


Link to post
Maes said:

By all means, don't tell anyone you're using CVS (though I've yet to see a convincing argument against it, or an obvious drawback).

Mocha Doom, I'm looking at you… Is there a tool that can quickly import a CVS chain into Git?

Second, is there a version control tool optimized for non-text files?

Share this post


Link to post

The fights between version control fans reminds me of the whole Emacs vs VI thing. Silly at the moment, but it'll hopefully bring a few chuckles in years to come. Who knows, maybe we'll even have a Church of Mercurial in the future.

Anyway, I personally stay out of it and just use what I'm most familiar with and what works best for me: Mercurial. If I had to use others, meh, no big deal. Unless it was CVS.

Share this post


Link to post
printz said:

Mocha Doom, I'm looking at you… Is there a tool that can quickly import a CVS chain into Git?

Second, is there a version control tool optimized for non-text files?


Both Git and Mercurial (distributed version control systems, or DVCSes as fraggle called them) come bundled with tools that can help you migrate code from older VCSes, and if you don't like the supplied tools, other people have written their own. Fraggle wrote one that converts from SVN to Git differently from the Git-supplied tool.

How do you want a version control tool to "optimize for non-text files"? Compression? Output of 'diff' between changes of binary formats? It would be hard to answer your question without a use-case that explains what you're looking to do.

Share this post


Link to post
fraggle said:

But beneath the hostility there is an important message. It's a good practise to always use version control if you're working on a project - even if it's a small project and even if you're the only contributor. When I first started using CVS years ago, I found that it helped give some needed structure to my work: instead of just editing random files and copying them around, you have to carefully construct and explain each change. That's as important for you as it is for anyone else who might be looking at your work.


I think this is the most important thing; to use something that does some kind of tracking of changes as opposed to using nothing at all, or rolling your own system, say for example copying files and adding dates/extensions or something similar to "keep track" of your changes. Being able to ask your VCS what changed over a period of time down the road can save huge amounts of headaches when you have to go figure things out.

My first maxim is: Blame the artist, not the tool. All VCS tools do pretty much the same thing, the differences lie in how the tools are used, and how you use them as a normal part of how you are doing whatever you are trying to do (how the tool integrates into your "workflow").

I still have repos in CVS, mostly because the effort required to convert them to something else isn't justified for how I use them (mostly read-only at this point).

If you're looking at learning a VCS from scratch, I would recommend any of the DVCS tools, such as Git or Mercurial; being able to work offline as well as not having to administer repos (SVN) IMO is worth the price of the somewhat steeper learning curve.

As far as Git vs. Mercurial, I recommend the same thing that I recommend as far as choosing a Linux distro, i.e. find out what tool people you know and trust use, then use that, the reason being, if you ever have questions, you already know a few people who are using the same tool, it's much easier to ask one of them then to try and find the right Google magick that will give you the answer to your problem.

Share this post


Link to post
spicyjack said:

How do you want a version control tool to "optimize for non-text files"? Compression? Output of 'diff' between changes of binary formats? It would be hard to answer your question without a use-case that explains what you're looking to do.

I mean being able to track changes to binary files (for example EXE hacks) or wad files (for example Doom mod revision tracking). I don't know how Git does it, but the tools I use can't track changes (i just see "modified" in the diff view), and I think it is not space-efficient either (unlike plain text diffs).

I already have a private Git repository of Doom work, but I'm considering backpedalling to DropBox, since it's already hard to remember changes to the WADs, and i prefer DropBox automatic save anyway.

Share this post


Link to post
printz said:

I mean being able to track changes to binary files (for example EXE hacks) or wad files (for example Doom mod revision tracking). I don't know how Git does it, but the tools I use can't track changes (i just see "modified" in the diff view), and I think it is not space-efficient either (unlike plain text diffs).


Generally, the only way a VCS will be able to show you the differences between binary files is if the VCS is written to understand the binary file format of the files in question.

Neither Git nor Mercurial (nor any other VCS that I know of) will show changes between successive versions of WAD files, but on the other hand, they won't show you changes to Excel/Word files, or PNGs, or JPGs or any other binary file format, they just say that the two files (old and new) are different.

AFAIK there's not even a standalone tool that will 'diff' two WAD files, although in theory it could be done, as the WAD file format is well-documented.

Have you thought about switching to a different WAD file format? UDMF (http://zdoom.org/wiki/UDMF) is text-based, so all VCS tools would be able to easily show you changes to the files that you make during editing.

Share this post


Link to post
printz said:

I already have a private Git repository of Doom work, but I'm considering backpedalling to DropBox, since it's already hard to remember changes to the WADs, and i prefer DropBox automatic save anyway.


That goes back to what fraggle was saying about having to think about what you're going to say in your commit messages when you make a commit. Think of it as present self leaving breadcrumbs for future self to follow.

Another thing that I find is very helpful is to keep a project journal. I use Markdown files, but plain text files work too, plus, VCSes will diff Markdown/plaintext no problems.

Share this post


Link to post

Showing differences between binaries won't be of much use, unless the tools used to author them are pretty consistent and with limited side effects, meaning that small changes in the represented data will only result in small changes in the binary data, and NO position shifts, rearrangements of data, change of dead/slack space, etc.

All assumptions that go out of the window if operations such as node building, lump rearranging, internal file defragmentation or cryptography take place everytime you save.

I can only see the usefulness of binary diff-ing if you operate directly on lumps/binary blobs OUTSIDE of a container format like .ZIP or even .WAD, and even then only few formats would leave you so little editing flexibility as to have to work directly in hex. Maybe some limited form of ROM hacking.

Share this post


Link to post
spicyjack said:

I think this is the most important thing; to use something that does some kind of tracking of changes as opposed to using nothing at all,

Yes, this is generally what I was getting at. If you're doing this you're already some significant portion of the way there.

You mention "rolling your own system". There's a temptation (as a programmer) to do something like this. The important thing to note is that version control systems have a fairly long history now. A lot of mistakes have been made along the way and what we have now are (I think) fourth generation systems. What can seem like an obvious solution actually turns out to be a terrible idea in practise. In short: designing a version control system is hard - much harder than you think it is. By using a modern system (like Git or Mercurial) you're building on the experience of the past ~20-30 years in the field.


My first maxim is: Blame the artist, not the tool. All VCS tools do pretty much the same thing, the differences lie in how the tools are used, and how you use them as a normal part of how you are doing whatever you are trying to do (how the tool integrates into your "workflow").

I think the saying goes, "a poor workman blames his tools". I think that misses the point. You could, conceivably I guess, use some kind of structured workflow as a substitute for a version control system: a document listing the procedure for how each change shall be made: how files will be copied and how the change will be documented. That would give you some of the benefits of a version control system, though would of course ultimately be inferior due to the possibility of human error.

I kind of see version control systems as prepackaged workflows, or perhaps it's more accurate to describe them as tools you can use to build workflows. It's interesting how older systems like CVS and Subversion are quite restricted in the workflows you can build around them - or at least they support some workflows better than others. Modern systems like Git are more flexible in that they let you use them in several different ways.

I think you're right that how the tools are used makes the biggest difference: Subversion vs. Git doesn't make much difference if you only have one branch, for example, and CVS vs. Subversion doesn't make much difference when you have a handful of files and not many commits. But there's no real reason to use choose Subversion or CVS nowadays: the newer DVCSes do everything they do, and in many ways do it much better.

printz said:

I mean being able to track changes to binary files (for example EXE hacks) or wad files (for example Doom mod revision tracking). I don't know how Git does it, but the tools I use can't track changes (i just see "modified" in the diff view), and I think it is not space-efficient either (unlike plain text diffs).

As I understand it, Git tracks changes to binary files (ie. internally uses some kind of binary diff algorithm), but that's there for the purpose of reducing the size of changes, rather than for presenting those changes to the user (which rarely is something that's useful).

Talking about Doom WADs, one thing I hoped to see back when UDMF was being designed was a format that minimized the use of indices (sector number, sidedef number, etc.) as that would have made levels easier to diff using a standard text diff tool (and perhaps even permit things like merges!). I'd still like to see an alternate text map format constructed like that, though I suspect it might be difficult to design. Obviously you'd want a visual diff tool as well to show you how the map has been changed.

Share this post


Link to post
fraggle said:

Talking about Doom WADs, one thing I hoped to see back when UDMF was being designed was a format that minimized the use of indices (sector number, sidedef number, etc.) as that would have made levels easier to diff using a standard text diff tool (and perhaps even permit things like merges!). I'd still like to see an alternate text map format constructed like that, though I suspect it might be difficult to design.

The OBJ model format allows negative index numbers to refer to the most recently specified vertex, for example "f -1 -2 -3" specifies a triangle face using the previous three vertices. Using that potentially makes a file produce smaller diffs, so long as face is defined shortly after where a vertex is defined -- it won't help if all the faces are defined after all the vertices.

For DOOM, the text format that id used was interesting in that it didn't define sidedefs or sectors (IIRC), each line specified the sector properties on each side and it was up to the processing tool to create the sectors. I'm not sure if it specified vertices, but you go the same route and just specify the start and end coords of a line, and let the tool create the vertices. So a text format with just LineDefs and Things (and no indices) is very doable.

Share this post


Link to post
andrewj said:

For DOOM, the text format that id used was interesting in that it didn't define sidedefs or sectors (IIRC), each line specified the sector properties on each side and it was up to the processing tool to create the sectors. I'm not sure if it specified vertices, but you go the same route and just specify the start and end coords of a line, and let the tool create the vertices. So a text format with just LineDefs and Things (and no indices) is very doable.

Interesting. I remember reading something - long ago - about the stair building linedef type: some of the uses of it in the IWAD maps use alternating dummy sector tags that don't do anything. Presumably that was to work around this detail of the Id level format.

My idea for an indexless format was to define linedefs implicitly. For example:

Sector {
    FloorTexture ...
    CeilingTexture ...
    Shape {
        Vertex 0 0
        Vertex 0 128
        Vertex 128 128
        Vertex 128 0
    }
}

Sector {
    FloorTexture ...
    CeilingTexture ...
    Shape {
        Vertex 128 0
        Vertex 128 128
        Vertex 256 128
        Vertex 256 0
    }
}
The two sectors join as a result of having two lines that intersect (0,128-128,128) and these translate into linedefs and sidedefs accordingly. It's more complicated than that, of course - you need to have some way to explicitly specify that you want the front or back side of a line - but the general idea would probably work.

Share this post


Link to post
fraggle said:

My idea for an indexless format was to define linedefs implicitly.


Way too many situations where there would be overlap or more than one way of creating those "implicit" linedefs in the engine, leading to non-unique interpretations -but yeah, the text file itself would change very little with small changes.

The problem with ANY way of describing a level is that you could e.g. scramble the order in which its structures are defined/created, and still get the exact same result, functionally. Any diff tool would show you tremendous differences, but nothing of consequence, unless you can somehow guarantee that Sector 73 will also be Sector 73 on the next save/node build etc.

Share this post


Link to post
Maes said:

I've not seen much hostility against using version control vs not using any at all (in the latter case, you're simply not considered "interesting" enough), but there are pretty obvious Holy Wars over which version control system you should use. By all means, don't tell anyone you're using CVS (though I've yet to see a convincing argument against it, or an obvious drawback).



If you do not see why CVS sucks you do not understand the purpose of revision control (note: there are no proper 'revisions' in a system that manages history on a per-file basis and doesn't assign a proper revision number/id. I had to work on a CVS managed project once and it was a complete and utter mess. Never again!

I'm also quite fed up with SVN, mostly because it's a slave to its server. Without server it's dead meat. The fact that its branching feature is a pain to work with is just icing on the cake.

For me it means I have lost all control over projects I worked at with past employers, because their SVN servers either do not exist anymore or I can't access them. I still got the code but no version history.

My personal preference these days is git, simply because it's the most powerful and most flexible one. Mercurial would be fine, too, but I find TortoiseHG rather clumsy compared to its SVN and Git counterparts.

Share this post


Link to post

The reason I can't take any "CVS sucks" arguments seriously is that the same people making those claims also largely claimed that SVN has t3h h4x and t3h p4wn, the "CVS killer", the "cure for the disease that is CVS" etc. only to abandon it and then, in retrospect having an equal -if not larger- amount of rotten things to say about SVN, including your very own statements:

Graf Zahl said:

I'm also quite fed up with SVN, mostly because it's a slave to its server. Without server it's dead meat. The fact that its branching feature is a pain to work with is just icing on the cake.


A-ha! And yet branching is something that the "inferior" CVS handles better than SVN, even by the admissions of proponents of the latter vs the former. Manual tagging and versioning also work fine for me, or at least they do exactly what I'd expect of such a function: I get my code up to a certain steady point? That's version "Stable ZUXYZY", if so I choose to call it. Perhaps it's the very good built-in support for CVS that Eclipse has that has somewhat biased me, I don't know how it feels when used with other tools.

Graf Zahl said:

For me it means I have lost all control over projects I worked at with past employers, because their SVN servers either do not exist anymore or I can't access them. I still got the code but no version history.


Another aspect where CVS wins over SVN ;-) Keep in mind, I wouldn't insist on beating this dead(?) horse if so many people hadn't pimped SVN up just because it wasn't CVS, only to make a heel-face turn as soon as other alternatives became available/mainstream. This indicates that their original belief was not genuine, but only fueled by spite or bandwagoning.

Share this post


Link to post

I still say, no matter in what ways CVS may be better than SVN, it's all undone by managing revisions per file.

I once had to work on a larger project using CVS with multiple persons and I lost count how often the lack of atomic commits caused us serious grief.

SVN, despite its glaring design flaws (the most annoying one being that tagging was a joke) never allowed anyone to screw up the repository, like a botched commit on CVS could do.

But as I said, I moved on. My current employer uses Git, as do all the open source projects I work on. And thankfully, this is a system that has been designed by people who knew what they needed, so most of the critical features are fast and powerful.

Another aspect where CVS wins over SVN ;-) Keep in mind, I wouldn't insist on beating this dead(?) horse if so many people hadn't pimped SVN up just because it wasn't CVS, only to make a heel-face turn as soon as other alternatives became available/mainstream. This indicates that their original belief was not genuine, but only fueled by spite or bandwagoning.


Now, that's just flat out bullshit. The problems with CVS are well known and well documented. Most users agree that SVN's flaws are minor in comparison. I could accept SVN's limitations but never CVS's.

So, there's nothing wrong with declaring CVS the Root of all Evil regarding VCS (something I wholeheartedly agree with) but then ditching SVN if something clearly better comes along. SVN was good for its time, but that doesn't mean it was perfect and it also doesn't mean to slavishly stick to it just to avoid being tagged as being 'bandwagoning' by Maes The Expert.

Share this post


Link to post
Graf Zahl said:

I still say, no matter in what ways CVS may be better than SVN, it's all undone by managing revisions per file.


Can you elaborate a scenario where this is a problem? And indicate what the "Right Thing" would be? No matter with how many people I discussed it, to me it just seemed a matter of perspective, either understanding one system and not getting the other, or viceversa.

After all, your hard work ends up altering files of source code...and when several of them are at a certain status, then that's your revision: you add a version tag which is essentially an elegant way of saying that "File X, version 1.4 and file Y, version 1.5 make up version 1.2 of my project", and be done with it.

Seriously, all this "CVS is broken! CVS is Evil!" propaganda sounds a lot like crying wolf.

I think CVS is to version control systems what Windows (or, if you want to narrow it down to one version, Windows XP) is to Desktop OSes: it may be old, may have its (well known) flaws, tons of less-than-flattering comments have been made about it and it will always have sworn enemies, but it's easy to learn, accessible, and, most importantly, is enough gets the job done for most people. Sure, there are more "powerful" alternatives (e.g. Linux), but under deeper scrutiny they turn out to be better suited for very specialized user niches.

Like XP and IE6, CVS it may be forever rough around the corners, but like an old worn glove or pair of shoes that have come to fit you perfectly, it's hard to let go, especially as long as it gets the job done ;-)

Share this post


Link to post

Yeah, whatever.

Don't accuse others of bias if you have such a strong one yourself.

The few occasions where I had to put up with CVS it appeared to be broken beyond repair so my general advice to everybody would be to dump it in favor of more modern alternatives.

Or to be blunt: CVS is shit (but so is IE6 - another tool where there's no excuse why people still use it.)

Share this post


Link to post

Posting a practical example of a situation where Git would "win" and CVS would "lose" would be much more helpful than saying that "CVS is shit", and lend some credibility to your argument. But don't throw a fit if I manage to reply with a CVS workaround/equivalent procedure afterwards.

Or, to put it bluntly, as you said: if you had to "sell" Git to a random developer, how would you go about it? This is a question open to everybody, not just you.

Share this post


Link to post

You know, you can post as many examples as you like, the main issue I have with CVS is the lack of one single feature, namely atomic commits. Anything it can and cannot do gets overshadowed by this single glaring design flaw and if I had to choose between a system with or without atomic commits I'd never ever choose the one without, all other features be damned. Fortunately CVS has been the last one of its kind that became popular.

My work on a team using CVS has been the most frustrating experience because half of the time the repository was trashed because one of the external devs had an unstable internet connection and constantly produced broken commits.

That's why I consider any revision control system without atomic commits so fundamentally broken that I strongly discourage their use under ALL circumstances and refuse to discuss their merits. For me this is the killer critria where CVS breaks down and absolutely nothing can salvage it anymore.

I had some previous contact with some so-called 'Enterprise' SCMs (a.k.a overpriced pieces of shit even worse than CVS) before, but the first real version control system I ever used was SVN. CVS only was years later when I had to work with some rather backwards-minded external teams but as I said, it was not an experience I liked. And most of the problems could be boiled down to using CVS which became a major hindrance.

I never claimed that SVN was perfect, but at least it got the fundamentals right: atomic commits and revision counting per commit and not per file. So communicating revisions for bug tracking et.al. was easy. Not so with CVS.

As for Git vs. SVN for me the exprience has been that I still can do everything I did before, only without all the artificial obstacles that SVN was constantly throwing into the way, the worst of all being that it becomes slow with large repositories.

Share this post


Link to post

Other than the revision counting per file (which can be worked around with manual versioning & tagging), I can understand how if you got burnt in circumstances where That One Feature (atomic commits) would've instead saved the day, CVS would certainly not be your favorite VCS.

On the other hand, I never had this particular problem, so I cannot directly relate to it.

As for the way SVN handles versioning compared to CVS, there's this interesting and somewhat extreme point of view, claiming no more and no less that CVS and SVN are meant for two very different jobs, which however just happen to partially overlap, and to a superficial observer, may appear identical.

It comes as no surprise that this has sparked so much grief: usually the most bitter bickering and Holy (flame) Wars occur when groups of users of two or more tools meant for different and yet somewhat overlapping tasks clash, often because they are really comparing apples to oranges without realizing it. Rarely is the resolution a mature "agreeing to disagree" or a realization of the different specifics at hand: they often "solve" those disputes with an "eat shit and die" excomunication (often unilateral), which of course does not create an environment open to newbies.

To the OP, if you wondered why you got treated like a leper showing his ugly mug around by merely asking for advice, that's part of the reason. You see, IT is a very diverse and fragmented field, and whenever there's more than one way of accomplishing something (which is often the case), it's simply one big can of worms.

A can of worms that manages to bring out all the hidden pettiness, thick-headed provincialism, high-horse attitude, trolling smugness, vitriolic hatred, a "we don't do thing X in OUR neck of the wood, you damn vagrant!" attitude, etc. All creating a toxic environment full of unmarked sacred Totems that Thou Must Not Touch.

Share this post


Link to post
Maes said:

Other than the revision counting per file (which can be worked around with manual versioning & tagging)



Here's one problem with that: It may work with a disciplined team, but not if several people work on the same thing - and especially not if the turnaround is too fast.

But in the end, why use a system that may cause specific and potentially serious problems, if there's other tools that do not?

It's obvious that CVS requires a lot more discipline from developers, something that's unfortunately absent in many freelancers.

Share this post


Link to post
Graf Zahl said:

Here's one problem with that: It may work with a disciplined team, but not if several people work on the same thing - and especially not if the turnaround is too fast.


Good point. It also explains why CVS is usually OK for a single developer, while more advanced systems just seem to add overhead and a steeper learning curve for reasons that are not immediately apparent -or might never be, depending on the project's needs.

Share this post


Link to post

To me, as a software engineer, somebody declaring they're not going to use version control on anything they intend to actually actively maintain and develop for months or years (ie. not a throw-away one-off program) is like somebody declaring they're going to drive down the wrong side of the road, or jump off a building, or drink anti-freeze.

I'd imagine that's why it garners ridicule from experienced users. Once you understand the benefits, you see that working the way you did before was a complete waste of your time. It's a paradigm shift, with all the accelerations implied by use of that term.

Share this post


Link to post
Maes said:

Posting a practical example of a situation where Git would "win" and CVS would "lose" would be much more helpful than saying that "CVS is shit", and lend some credibility to your argument. But don't throw a fit if I manage to reply with a CVS workaround/equivalent procedure afterwards.


Examples:

I am on a plane doing work on my laptop without an Internet connection and I want to commit a change.

I am working on a project with branches.

I am making a large commit and I lose my Internet connection halfway through doing the commit.

I am hosting my code on a remote server and the hard drive on the server dies.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×