Revision control and the Internet

[Maes]

Quasar said:

...somebody declaring they're not going to use version control...[snip] 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 don't think the OP declared that any point, or at least didn't say so here. If he did, then it's understandable that he would be treated badly if asking for (time-consuming) advice on something he didn't intend to use, and made it obvious.

What I understood, is that he googled about it and saw a lot of the hatred, provincialism, vitriol etc. I mentioned before, aka he stumbled upon many discussions where the subject of VCS was "elevated" to the status of a Holy War, and everybody in IT knows how bad these can get. In any case, there's the reply to his "why is that" question: Version. Control. Is. Serious. Fucking. Business. And that in the colourful and diverse IT world, obviously anyone not using YOUR same tools and patterns must eat shit and die :-)

fraggle said:

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

"You hold it, turd!" (shamelessly ripped from Major Payne).

Jokes apart, that's really grasping at straws. No matter how important it is, since you can't really commit it anyway because of no internet, what good does it do "committing" it on your computer? Can't it wait?

fraggle said:

I am working on a project with branches.

CVS has me completely covered on this one.

fraggle said:

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

Learn to commit one file at a time, if you know you're on a problematic connection. I've had a few abortive commits due to random errors, however I haven't had that "corrupted repo" problem people seem to mention a lot. At most I had to resume the commit halfway.

fraggle said:

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

I don't see how a crashed CVS server is any different from a crashed GIT server, if you are on a "virgin" workstation and need somewhere to check out code from for the first time. It's not that GIT will somehow magically overcome the laws of physics and deliver you your code anyway.

I know what you'll counter with: "A-ha! But with GIT I have a local copy of the repo!". Well, that's assuming you managed to do at least one checkout from that server before it crashed. You'd have the same with CVS, too.

I also know what's next: "Yeah, but with GIT, I can continue doing commits and when the server is back again, I can finally push them!". OK, this might be GITs only real advantage: that you can continue having a normal versioning workflow even in absence of a functional remote repository, and only "push" stuff when a connection is secured.

The closest you could get to that with CVS would be to have a strictly local CVS server running on your dev machine, and periodically copying it to an external location with special tools, obviously not the intended way of using it.

Again, I think the gist of this discussion is that GIT only has an advantage for a developer if he happens to need its specific features. If not, there are easier alternatives to setup and learn.

[Graf Zahl]

Maes said:

Jokes apart, that's really grasping at straws. No matter how important it is, since you can't really commit it anyway because of no internet, what good does it do "committing" it on your computer? Can't it wait?

No, no, no!!!
If you dismiss this point you are really not understanding the real power of DVCS (which, btw, is not the access to the remote but the ability to work offline, do commit, branch, delete the branch, experiment around with FULL BACKUP FACILITIES thanks to the VCS you are using. This is an incredible asset but you'll probably won't understand if you haven't adjusted your workflow to it.

With Git you can just do stuff, commit it and then later decide whether to scrap it completely, push it to the working branch or crate a new branch, or whatever. You got a full local repository, so let's use its advantages instead of discussing the merits of ancient software.

Learn to commit one file at a time, if you know you're on a problematic connection. I've had a few abortive commits due to random errors, however I haven't had that "corrupted repo" problem people seem to mention a lot. At most I had to resume the commit halfway.

Uh...
... learn to use tools that just do the job out of the box instead of adjusting the workflow to a deficient tool?
Sorry, but if this is how you try to defend CVS agaist Git, I prefer to laugh at you. Sorry.

I don't see how a crashed CVS server is any different from a crashed GIT server, if you are on a "virgin" workstation and need somewhere to check out code from for the first time. It's not that GIT will somehow magically overcome the laws of physics and deliver you your code anyway.

Now sorry, but that's an utterly retarded fringe case. The real danger is an offline remote while working on the code and trying to commit before moving on. This is a serious show stopper that more than once ground work for me to a halt when still using SVN.

As for the rest of your questionable reasoning: Take only one guess why so many projects are moving away from centralized VCSs. It has nothing to do with Git being 'in', but with Git being fundamentally better.

Take ZDoom and GZDoom as an example. In SVN times each code update was a major hassle because we were dealing with two distinct repositories so each merge had to be carefully done.

Now, GZDoom is based on a clone of ZDoom so all I have to do for an update is to pull ZDoom's remote and then push to GZDoom's. As an added bonus I get the full commit history. This wasn't possible before.

Another bonus is that external contributors can make a clone, implement some stuff and then send a pull request. So, how can such more sophisticated setups be performed with CVS. I doubt you can give a satisfactory answer to that.




I won't comment on the rest because it's pointless. It clearly shows that yout

[Maes]

Maes said:

Version. Control. Is. Serious. Fucking. Business. And that in the colourful and diverse IT world, obviously anyone not using YOUR same tools and patterns must eat shit and die :-)

OK, I got it, just let me get into a comfortable corner first. Can I have my shit served on a plate with lolis, at least?

[Blzut3]

Graf, you just responded to Maes in exactly the way he wanted you to. :P Lets try this without the insults.

I haven't used CVS for any extended period of time, so I can't comment why SVN is considered so much better. I will comment in general why DVCS over CVCS.

Maes said:

Jokes apart, that's really grasping at straws. No matter how important it is, since you can't really commit it anyway because of no internet, what good does it do "committing" it on your computer? Can't it wait?

The fact that you're arguing that point that you can't really commit back to the server shows one weakness in CVCS. This is one of the many reasons that merging is made easy with DVCS. When you get connected you can pull any new changes, merge, and then push back to the remotes. All of this is done while preserving change history.

On a related note, this is also one of the many ways DVCS highly encourages small but frequent commits. Each commit should be a single change rather than your work for the day/week. The end result is should something go wrong, you have a more fine grained view the changes. Contrast to finding the culprit revision and going "OK, which of these bullet points caused the problem."

Maes said:

CVS has me completely covered on this one.

CVS covers branching, but does it do branches as well as Mercurial or Git? In a DVCS branching is almost an implicit operation (remember that working offline example? Well that has a chance of creating a branch). DVCSs encourage small unnamed branches when merging changes from multiple sources, and if something becomes long term, just slap a name on it after the fact.

I know this seems like a weak argument, but if one works with the intended DVCS work flow, the difference is night and day. It's difficult to explain why you would want to be branching all the time without sounding somewhat silly.

Maes said:

Learn to commit one file at a time, if you know you're on a problematic connection. I've had a few abortive commits due to random errors, however I haven't had that "corrupted repo" problem people seem to mention a lot. At most I had to resume the commit halfway.

Commit one file at a time? A commit is supposed to be a snapshot in history relating to some change (described in your commit message). Having singular file commits would make bisecting somewhat difficult.

Maes said:

I don't see how a crashed CVS server is any different from a crashed GIT server, if you are on a "virgin" workstation and need somewhere to check out code from for the first time. It's not that GIT will somehow magically overcome the laws of physics and deliver you your code anyway.

I know what you'll counter with: "A-ha! But with GIT I have a local copy of the repo!". Well, that's assuming you managed to do at least one checkout from that server before it crashed. You'd have the same with CVS, too.

I'll quote my professor on this one: "It's OK to have multiple working copies!" (He was talking about a SVN repo by the way.)

The theory here is some non-"virgin" computer would have a backup. On a typical centralized system, if the server crashes all history is lost. By the way, the only thing special about the source repository is that it's location is memorized, if the server is down you can still pull or clone from another computer given proper set up (or temporarily set up the repository elsewhere).

Maes said:

Again, I think the gist of this discussion is that GIT only has an advantage for a developer if he happens to need its specific features. If not, there are easier alternatives to setup and learn.

One of the big advantages you didn't mention is the social aspect of DVCS. As Graf just mentioned, with a DVCS you can fork a project while still keeping in sync with the parent's history. This means all meta data is kept such as who changed what.

Related to that, you don't need to bless a select group of people with write access to the repository. If used properly, a DVCS allows you to pull changes from random people. The changes will preserve their history and their author. Once again this helps should you need to bisect the cause of a problem.

Edit: Clarified a horribly worded sentence.

[fraggle]

Maes said:

"You hold it, turd!" (shamelessly ripped from Major Payne).

Jokes apart, that's really grasping at straws. No matter how important it is, since you can't really commit it anyway because of no internet, what good does it do "committing" it on your computer? Can't it wait?

Committing is not the same as sharing that commit. Version control is bookkeeping, not collaboration.

CVS has me completely covered on this one.

Come back when you've actually tried it on a large project, with lots of branches, and try telling me it works.

Learn to commit one file at a time,

*Snort* Okay, sure. You're at the point where you're working around a broken system at this point. The limitations of the system you're using shouldn't be dictating how you record your revision history.

I don't see how a crashed CVS server is any different from a crashed GIT server, if you are on a "virgin" workstation and need somewhere to check out code from for the first time. It's not that GIT will somehow magically overcome the laws of physics and deliver you your code anyway.

I know what you'll counter with: "A-ha! But with GIT I have a local copy of the repo!". Well, that's assuming you managed to do at least one checkout from that server before it crashed. You'd have the same with CVS, too.

Uh, no. Either you're confused about how Git works or you're trying to use some kind of weird twisted logic to argue your point here.

In Git, there is no distinction between "repository" and "checkout". If you have a checkout you have a copy of the entire project history. As does every other developer. If you're using a server then the implication is that there are already at least two copies of the repository: your own, and the one on the server. Git also makes it easy to push your repository to other servers as well.

I don't know if the point was "with CVS, you still have your local checkout, you've just lost the entire revision history". I don't think these are in any way comparable. Revision history is important. If you don't care about revision history you might as well not even bother using a version control system in the first place.

Graf Zahl said:

As for the rest of your questionable reasoning: Take only one guess why so many projects are moving away from centralized VCSs. It has nothing to do with Git being 'in', but with Git being fundamentally better.

Can't agree with this enough. Maes is acting like DVCS is some kind of trend: it isn't. Using a DVCS brings real, tangible advantages.

[Ladna]

In which Maes trolls every goddamn developer on Doomworld.

CVS is fine if you're a single developer who doesn't care about history.

Why single developer?

You can lock files forever

...so they can't be edited (yes you can force unlock or whatever but pfff).

There are no global revisions

Let's say I want to checkout the last actually working version of Mochadoom. I have no way of finding that revision, because it doesn't exist. If I'm the sole developer of the project then I inherently know what the last working version is, because I mostly remember everything. To contributors though, you may as well hang a sign on the website that says "FUCK OFF, OR GOOD LUCK, WHATEVER"

CVS is server-based

There are 2 parts to this:

1. If the server's down, no one can get the code and no one can commit changes. This is probably fine if you're the only developer. It's not so great if a dozen or so people are all now fucking off because they can't commit changes (and thus have the server run hooks like tests, publishing, doc updates, etc.). It's also not so great if you rely on CVS to publish your source instead of periodic source releases, because now no one can download it.

2. If the server never comes back up, now you have no history and no way to merge the 12 different changes all your developers were working on. Depending on how long the server was down, this can be extremely goddamn aggravating - Graf Zahl levels of aggravation.

Why "doesn't care about history"?

CVS is server-based

The server drive goes, your history goes.

Backups are by definition always out of date

Backups have to be updated all the goddamn time; which no one will do because doing it sucks, which makes the backups useless. You'll just end up starting over from the latest "rev".

CVS corrupts your source tree

CVS can do this in several relatively common ways (one might say any possibility of this happening is too common).

There are no global revisions

So there's no way to say, "this is the rev where X works". Even if you could, you couldn't check it out anyway. But Hooray, Labels!

Why is SVN better?

You can't lock files at all.

There are global revisions.

It doesn't corrupt your data, pretty much no matter how hard you try.

Although you do still have to back the server up, you can set up SVN hooks to do this for you so your backups aren't useless

No one cares about labels because SVN has tags.

No one cares about branch merging because we have great tools for that already; it's not the job of VCS.

Why is DVCS better than SVN, and by the transitive property of beating better than CVS?

Every checkout is a full repo copy

If the server dies, you have a comprehensive, perfect backup of version history on your machine, as does everyone who checked out your project. Every time you Pull/Update you update the backup.

Tags & revision names/labels don't suck

You can tag and name revisions without creating a whole separate copy of the goddamn codebase.

Branching and merging are hilariously easy

In fact, they're part of normal DVCS workflow.

You don't need a server

This also has more than 1 part:

1. I get all the benefits of version control without ever talking to the server. Let's say I'm on campus where the wireless is about as useful as a condom in the Congo. If I can avoid waiting on the network, I'm super happy. Let's say I commit 3-4 changes working on a full-color renderer on my whiz-bang source port SuperDoom. Let's say while working on revision 5 I realize I've been missing a great way to organize all this shit, and revisions 1-4 that I just committed were a big waste of time. I can use any one of a number of DVCS features to make those revisions go away or part of a different branch or blah blah blah. This whole time I haven't touched the network even once. When I get home, I finally push my changes to my central repo on buttbucket.org. Goddamn, DVCS is the best.

2. I don't even need a server. Let's say buttbucket.org's terms of service are shitty, or I'm working on a DVCS hosting site and I don't want the slimedogs at buttbucket.org to see my awesome code that will destroy their business model and thus their lives. My team and I can share code over SSH or HTTP or whatever the fuck we want; it's decentralized and baller, and every time we pull changes from each other we create an updated backup on our machines. Goddamn, DVCS is the best.

[Maes]

Ladna said:

Let's say I want to checkout the last actually working version of Mochadoom.

Good practice in CVS projects dictates that this is the HEAD branch, though that reflects the latest working development, rather than the latest released version ;-) For that, you simply switch to the tag assigned to version 1.6, as of now. Extremely easy to do with Eclipse's CVS plugin.

There are no global revisions

So there's no way to say, "this is the rev where X works". Even if you could, you couldn't check it out anyway. But Hooray, Labels!

I don't know what you are talking about. I can mark perfectly fine "milestone" versions with a descriptive tag, and anyone with a half-decent CVS client can switch to that version. I don't get why it's considered so hard to do.

In any case, Git sounds great if you need its features, and feel that the learning curve is worth the effort. It certainly isn't beginner-friendly, or ideal for a single developer.

The problem is that CVS is treated as if it somehow was broken or a scam and didn't do its job as a VCS, while EVERYTHING else is t3h p4wn and t3h h4x, which is clearly untrue.

IMO, if you have to debate so bitterly and with so complex arguments trying to "sell" anything, then perhaps the advantages are paper-thin or even not there at all? If Git was really so great it wouldn't require walls of text to come up with convincing -if convoluted- scenarios. CVS just works, and that's all there is to it. Don't fix what ain't broken, I say.

[Graf Zahl]

Maes said:

The problem is that CVS is treated as if it somehow was broken or a scam and didn't do its job as a VCS, while EVERYTHING else is t3h p4wn and t3h h4x, which is clearly untrue.

No, it is true. It is broken. For many use cases it is utterly useless. I concur with the statement that the only viable use case for CVS is single developer, single checkout, all knowledge about the project concentrated in one person. Beyond that, Nighmares ensue.

[Ladna]

So do me a favor and tell me which of these labels work:

HEAD
AWTEvents
Alpha16
Alpha16Alpha16RenderRefactor
Anaglyph
Callbacks
ColFuns16
DemoTooling
Experimental
HiColor
HiColor16FlashingDisk
Root_AWTEvents
Root_Anaglyph
Root_DemoTooling
Root_Experimental
Root_HiColor
Root_angle
Root_finnw
TechDemoV15
TrueColor
UnifiedAlpha
angle
finnw

Is it supposed to be HEAD? It has like 400 errors in Eclipse. Is it UnifiedAlpha? It also has around 500 errors. What about Alpha16? There isn't even an Eclipse .project in it. Man, Labels are so useful. *rolleyes*.

[exp(x)]

Ladna said:

In which Maes trolls every goddamn developer on Doomworld.

Seriously. Go back under your caveman bridge, Maes.

[printz]

Bah. Git seems easy both from graphic tools (SourceTree and TortoiseGit ahoy) and even from command line (intuitive syntax and user-friendly feedback). I don't get why people say it's hard.

[Maes]

All versions will give you a lot of apparent errors, but they are mostly concentrated in the testers package (mostly obsolete/broken by now, should probably clean it up). Errors in other packages are usually unused/nonfunctional modules which "maybe" I'll complete one day. In any case, they do not affect functioning.

Yes, the very-very-very-very latest I've been working on is ALWAYS in HEAD (CVS conventions, FTW!), which may be more advanced that the currently released version ;-) The latest "official" release is of course Alpha16. Previous one is "TechDemoV15" (v1.5) and before that...well...let's say I was less careful about marking versions. BUT this had nothing to do with CVS per se, you damn weasel ;-)

The other labels are mostly for my own use, added at various phases of developing, or signaling branches (I'll only say that "DemoTooling" is of some relevance now ;-)

Oh and there also was the infamous sourceforge CVS and SVN crash at the beginning of 2012 which wiped out all previous info, so the only way to see "where I was" before that, are my own zip backups I took "just in case".

[Ladna]

printz said:

Bah. Git seems easy both from graphic tools (SourceTree and TortoiseGit ahoy) and even from command line (intuitive syntax and user-friendly feedback). I don't get why people say it's hard.

It used to be really obscure. Mercurial had kind of a 1:1 mapping between hg and svn, git wasn't really close; it was a whole different way of using revision control.

Further, Git is written in lots of different languages, C, Shell and Perl. I understand it's undergone something of a unification now, but at the time people who were evaluating DVCS' were like, "WTF is this Frankenstein shit going on in here?" In contrast, Mercurial is all Python and writing plugins was comparatively straightforward... so long as you knew Python (read: are a developer and not an idiot).

Plus TortoiseGit/SourceTree are relatively new, TortoiseHg was out way before either of them. Ease of use on Windows was a huge selling point of Mercurial in the early days.

Git stayed in the game because it was a lot faster over the network (like, insanely fast), all Linux kernel devs used it, and because GitHub made it nice to use for Ruby and JavaScript developers. Even today when you look in GitHub like, 80% of the projects are Ruby & JS.

Now though, it's a wash. Git is slightly faster over the network, not much though. Mercurial is slightly easier to use, not much though. bitbucket.org (Mercurial hosting site) supports both Mercurial and Git, although github.com supports only Git and Subversion (dicks). I think Google Code does Mercurial and Subversion, for orthogonality's sake.

Maes:

Oh cool OK. I suggest putting a tab on your site for something like this though; I've downloaded so many goddamn tags I lost count. Thanks :)

[Graf Zahl]

Maes said:

Oh and there also was the infamous sourceforge CVS and SVN crash at the beginning of 2012[/b] which wiped out all previous info, so the only way to see "where I was" before that, are my own zip backups I took "just in case".

Ha! Got you. With Git that couldn't have happened. You wouldn't need your Zip Backups at all, because you could have restored the ENTIRE repository from your local clone!

[Maes]

Graf Zahl said:

Ha! Got you. With Git that couldn't have happened. You wouldn't need your Zip Backups at all, because you could have restored the ENTIRE repository from your local clone!

Hmm...now that I remember it, it was a temporary lockdown rather than a crash, it affected CVS repos and other services (but not SVN), and it was in 2011 (damn memory...)

For a brief stint I had created a parallel SVN repo, but I had to delete it at some point due to a bad upload, and opted to go back to CVS as soon at it was unlocked. Other than that incident, I don't remember SVN negatively, but I wasn't particularly impressed, either. In any case, that SVN repo was created by -guess what- my local files at the time, "continuing" where the CVS left off.

At some point the lockdown was removed, and I simply committed the -now wildly different- files to the CVS, as if nothing had happened. Of course don't expect any history/commit info to have survived two incompatible repo transitions during that period.

[fraggle]

Maes said:

For a brief stint I had created a parallel SVN repo, but I had to delete it at some point due to a bad upload, and opted to go back to CVS as soon at it was unlocked. Other than that incident, I don't remember SVN negatively, but I wasn't particularly impressed, either.

Not very surprising: apart from atomic commits there isn't a huge amount of difference between CVS / Subversion. Subversion was explicitly created with the mission statement of being "a better CVS". Just having atomic commits makes quite a bit of difference in practice though.

The difference between CVS/Subversion and DVCS systems like Git/Mercurial is much bigger than the difference between CVS and Subversion. They work in a very different way.

In any case, that SVN repo was created by -guess what- my local files at the time, "continuing" where the CVS left off.

At some point the lockdown was removed, and I simply committed the -now wildly different- files to the CVS, as if nothing had happened. Of course don't expect any history/commit info to have survived two incompatible repo transitions during that period.

This kind of brings me back to my original point that I've been trying to make throughout the thread: version control is bookkeeping. I commit to make a logical change, not to just "check in my latest changes". It's why your earlier suggestion of "learn to commit one file at a time" is so laughable: it misses the entire point of how and why I use a VCS in the first place.

If I was in that situation, I would have made a lot more effort to try to preserve that history. It's why I'm not satisfied with just having the contents of my local checkout. I want that history. For me the history is almost as important as the code itself. It's why I've gone to the effort of writing my own Subversion-Git conversion tool for Chocolate Doom - I wasn't satisfied with any of the others!

It sounds like you have a different mindset to Graf Zahl or I, that you maybe haven't fully understood or embraced how a VCS is supposed to be used. Is a VCS just a backup system to you, or a way of storing or sharing code? How do you see it?

[Maes]

fraggle said:

It sounds like you have a different mindset to Graf Zahl or I, that you maybe haven't fully understood or embraced how a VCS is supposed to be used. Is a VCS just a backup system to you, or a way of storing or sharing code? How do you see it?

Since I started using VCSs as a professional tool (at a shop which used and uses CVS, though), I viewed them both as a convenivient backup and a collab tool. Much better than zip backups....which however MAY come in handy -and don't get me started about the MEDIA used ;-)

We did our "history tracking" through careful commit comments and version tagging whenever we reached some milestone. Not hard to do, as we are -still- only two developers. I later just used CVS for Mocha by virtue of having picked up on it naturally.

My colleague now suggests moving our codebase(s) gradually to Git but if he -a seasoned multi-framework hardcore LAMP & web developer and Linux guru- required a "week of personal re-education" (in his own words) to wrap his mind around it and be in the position of explaining the basics to me, then it must be radically different than what we have used so far.

[Graf Zahl]

Maes said:

My colleague now suggests moving our codebase(s) gradually to Git but if he -a seasoned multi-framework hardcore LAMP & web developer and Linux guru- required a "week of personal re-education" (in his own words) to wrap his mind around it and be in the position of explaining the basics to me, then it must be radically different than what we have used so far.

Not radically different, just a lot more powerful. If your workflow is just 'change code, commit, change code, commit' it won't be any different, you just need to remember that commits in Git are local, you have to push to send it to the server.
Where the learning sets in is to actually make use of that newly acquired power that Git provides.

Of course, if someone says he needs a week of 'personal re-education' my suspicion is that this person is doing something wrong. Get used to the basics first (i.e. what you did with the old system) and once you feel comfortable start to explore.

[Ladna]

Maes said:

Previous one is "TechDemoV15" (v1.5) and before that...well...let's say I was less careful about marking versions. BUT this had nothing to do with CVS per se, you damn weasel ;-)

Well yeah I'll cop to a little strawman there, but it was part of a legitimate gripe. Yeah I could see the labels in TortoiseCVS but I couldn't see shit else, not a file tree, not a date of last revision, not a diff, nothing. That's because this information only exists on a per-file basis in CVS, so TortoiseCVS would've had to download a shitload of info just to show me that stuff. You can see how this is the case by just browsing the source tree inside TortoiseCVS; every time you click on a folder to expand it it pops up a "contacting CVS server" dialog box (or whatever), that takes like 10 seconds. Fuck that.

In Subversion, it's really easy to find a release rev if (for some unholy reason) there is no tag. You just look at the revision log. If the devs put some asinine commit message for that rev that has nothing to do with a release, you can just update/switch around until you find the one you're looking for; this is pretty fast, especially compared to CVS. In a DVCS the same thing applies except it's basically instantaneous (I have an SSD).

===

It is 100% worth the effort to learn to use Git/Hg. Eclipse has baller plugins for both so you don't even need to learn anything, especially if you're just using your VCS as an archive. If nothing else, just get a GitHub/Bitbucket account and work on a little throwaway project just to see the pretty things those sites will do.

[chungy]

Maes said:

I don't see how a crashed CVS server is any different from a crashed GIT server, if you are on a "virgin" workstation and need somewhere to check out code from for the first time. It's not that GIT will somehow magically overcome the laws of physics and deliver you your code anyway.

I know what you'll counter with: "A-ha! But with GIT I have a local copy of the repo!". Well, that's assuming you managed to do at least one checkout from that server before it crashed. You'd have the same with CVS, too.

This is where you seem to be failing to understand the "distributed" part about DVCS. By design, the system is not actually tied to any single "server". Having a central repository to push to and represent a canonical version of a piece of software is convenient, but nothing about git enforces that ANYTHING has to be communicated to it at all. You are free to clone it and work on it however you wish, even publishing your own fork for others to see, and it also tends to be the most common way to submit contributions (GitHub making it really easy with an automated "Pull Request" helps, but you don't need GitHub nor anyone else to pull off the same thing).

In Git and most other DVCSes, all objects (commits, tags, branches, etc) are described with a cryptographically secure hash, namely sha1. It can be used to check the integrity and validity of the repository. Quite literally, if sourceforge or github died, almost(*) everybody's clone of the repository can be used to restore it, since they're pretty much backups. You can also shave off the top local commits before republishing said repository, but if the sha1sums match up with the old, you pretty much have a guarantee that the old data was never tampered with.


(*) Almost because git does support shallow clones -- ones that do not contain the entire repository history. They are rather limited in operation but usually suit well to one-off events in large repositories (say, you don't want to download the ENTIRE Linux history just to make a spelling fix). Long-term development should always be started with the full (default) deep clone.

[Maes]

Now I'm waiting for someone to come up with a backwards-compatible, retrofittable two-tier CVS extension: running a local CVS server, which can however sync with an external "authoritative" one, if need be, stealing the thunder of DVCS.

This way it will buy CVS another 20 years lifetime, and piss off everyone* at the same time ;-)

Spoiler

*Well, those stuck up enough to realize CVS's simplicity and elegance, at least. Kinda ironic that all this "Less is More" and "Worse is Better" hacker wisdom doesn't seem to apply to VCS...

[Graf Zahl]

LOL!

Sorry, Maes, but I really have the feeling you do not understand what this is all about if you defend CVS this rabid. It's a child of another time and its features driven by a completely different internet infrastructure than what we have today.

This isn't about 'less is more' but about choosing the tool that will offer the most benefit long term. Well, not even just long term, if you have to adjust your workflow to the tool (commit each file separately, heh?) you already admitted that the tool is inadequate.

To me this whole debate from your side sounds like someone who grew up with certain working patterns and sticks to such patterns far longer than is good for anyone. And that in an industry that normally loves to see people who are willing to learn and embrace new technologies.

Oh, BTW, I really doubt there'll be much improvement on a dinosaur like CVS. It's old, crusty and obsolete. Ever more people will eventually abandon it until only the die-hard learning resistant ones are left.

[Maes]

I even thought of a name for this advanced CVS: TrollCVS



with Advanced Troll as a mascot ;-)

[chungy]

OpenBSD devs have already been using CVSync for over a decade, which is basically the gross hack to retrofit CVS to working with offline full clones and all.

It's still CVS. It still has per-file history, merging sucks, branching sucks, and it can't even guarantee what you put in is what you get out. Cobbling together a semi-distributed system for it (as OpenBSD already has) doesn't fix anything. Frankly, I think OpenBSD is insane for continuing to use it.

I await your speculation on why it never took off :)

[Maes]

chungy said:

I await your speculation on why it never took off :)

There's your killer:

chungy said:

OpenBSD

However, just one, honest question: exactly how does merging "not suck" with other VCSs? From my experience, merging is always a painful affair where you have to manually check almost everything highlighted as a difference, in order not to pull any breaking changes. Hardly a matter of giving a single command and somehow all non-conflicting changes (or even those) seamlessly merging with your codebase, as the praise of anything not-CVS leads to believe.

[chungy]

Indeed, because OpenSSH is such an abysmal failure. Oh wait.

(FWIW, OpenBSD didn't originate CVSync, but they're probably the biggest user of it.)

[Graf Zahl]

Maes said:

There's your killer:



However, just one, honest question: exactly how does merging "not suck" with other VCSs? From my experience, merging is always a painful affair where you have to manually check almost everything highlighted as a difference, in order not to pull any breaking changes. Hardly a matter of giving a single command and somehow all non-conflicting changes (or even those) seamlessly merging with your codebase, as the praise of anything not-CVS leads to believe.

The suckiness of merges depends on the level of automation a VCS has to offer. And let's stick to realistic work cases here.

The system needs to know where a file originated from, when it was merged the last time (in both directions) and some other stuff.

I still remember old SVN which didn't have merge tracking so 90% of all supposedly automatic merges had to be manual. With CVS this is probably much worse because it doesn't even know the concept of revision.

On the other hand, modern DVCSs depend much more on merging capabilities and to no surprise their ancestry management is a lot more reliable and therefore their merging a lot more straightforward.

Of course, if there's a real conflict it has to be resolved manually. But DVCSs throw far less of those.

[fraggle]

Maes said:

However, just one, honest question: exactly how does merging "not suck" with other VCSs? From my experience, merging is always a painful affair where you have to manually check almost everything highlighted as a difference, in order not to pull any breaking changes. Hardly a matter of giving a single command and somehow all non-conflicting changes (or even those) seamlessly merging with your codebase, as the praise of anything not-CVS leads to believe.

The simple answer to this question is that it's easier to implement better merge algorithms when you have the full history locally available to you.

Subversion has a scheme called "mergeinfo" that stores metadata that it supposed to help with merges. But even though it works better than CVS, it still isn't great - there are a whole bunch of corner cases it can't handle. File renames/moves are one example. I find that lots of the merge conflicts I have to deal with when using Subversion are products of the tool and its inability to resolve problems, rather than actual, bona-fide conflicts.