Ways of working

[JackScott]

Practicality: "1.1 RC1" is a release, but you may still need to release a "1.0.5" because of an urgent security issue

A release candidate is not a production release. Quoting from the page I linked earlier:

Therefore, each time when changes are merged back into master, this is a new production release by definition. We tend to be very strict at this, so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master.

Maybe this could be solved by having a seperate branch where things are tagged with "non-production releases". That's a solution that comes quickly to mind (and I don't particularly like it either). I'll admit I haven't thought about that problem in great detail.

Being a good upstream: You make distribution packagers and end users a lot happier if you have a defined release support timeframe - and, if what you are developing is a platform of some sorts - it is downright rude to force someone to choose to either accept something being broken or having a security hole.

This isn't a problem with version control. I agree that this model makes it more difficult to support multiple major versions at once... but we shouldn't have to. I'm a major supporter of rolling releases, which fit in perfectly with this model. When a user runs the update tool for their system, it should fetch the latest production release. Any software engineer that breaks backwards compatibility deliberately should be punished into eternity (yes, I'm looking at you, Guido van Rossum).

[Owen]

This isn't a problem with version control. I agree that this model makes it more difficult to support multiple major versions at once... but we shouldn't have to. I'm a major supporter of rolling releases, which fit in perfectly with this model. When a user runs the update tool for their system, it should fetch the latest production release. Any software engineer that breaks backwards compatibility deliberately should be punished into eternity (yes, I'm looking at you, Guido van Rossum).

I'm not opposed to backwards compatibility breaking releases for some things - sometimes, it just makes sense to drop support for deprecated functions, as long as the old version of the library will remain available. For example, I'm not opposed to the removal of deprecated functions in libarchive 3.0.

But even in the case of no intentional backwards compatibility breaking changes, there may be unintentional ones. I think its warranted to give somebody a grace period between when a new version is released and when security and major bug-fix updates for the previous version cease. Most of the time, I find that supporting multiple verisons is actually trivial; the only time it becomes tricky is if there have been any major restructuring between versions; in that case, you owe it to your users to support the old release for a reasonable period (because there is a high probability that you've broken *something*)

[Solar]

Any software engineer that breaks backwards compatibility deliberately should be punished into eternity.

That is assuming that the current state of affairs isn't FUBAR. Which, unfortunately, it quite sometimes is.

[rdos]

I moved to my current webhotel many years ago because they offered one-click installation of SVN. I would not move again unless the new web-host had one-click SVN install. Like Solar, I also use svn update to sync my development files between multiple machines at multiple locations. It is far easier than any other solution.

The web hotel offers backup, but other than that, I also keep the source on many machines just in case. However, I don't have my own backup of the change history (the SVN repository). I also have some older versions on CDs / DVDs.

[bluemoon]

Some of my backup CD 6 years ago are now unreadable. Now I never backup to CD again and I only trust backup to multiple remote servers, and I relocate backup files on my local computer to new hard disk every a few year.

[Solar]

However, I don't have my own backup of the change history (the SVN repository).

My hoster provides, in the admin interface for the SVN services, a way to download the "svn dump" output (i.e., the whole repo including history). I'd daresay your hoster provides the same. If not, shame on him. If you just don't use it, shame on you.

[rdos]

However, I don't have my own backup of the change history (the SVN repository).

My hoster provides, in the admin interface for the SVN services, a way to download the "svn dump" output (i.e., the whole repo including history). I'd daresay your hoster provides the same. If not, shame on him. If you just don't use it, shame on you.

I can see the repository with FTP, and I could potentially zip it from the shell. It is just that I don't think my web hotel will cease to exist or something in the near future. I've had my account there since 2003. I also have many SQL databases there, which I have even worse backup on. Those are several GBs large by now.

[Solar]

I don't mean the ZIP of the repository file structure. I mean the output of "svnadmin dump /path/to/repository". That is what you'd want, and any self-respecting SVN hoster should give you access to it, either through SSH access with appropriate permissions, or through some admin interface.

[Kevin]

Have you considered using a DVCS instead? It would solve the backup problem automatically.

But if for some reason you don't like to use any of them for your daily work, you could still have an additional git-svn checkout just for backup purposes.

[Solar]

That had to come up, hadn't it?

Yes, I "considered it", I tried it, and I hate its guts. The documentation stinks, the user interface stinks, and the workflow is needlessly complicated unless you are actually doing the kind of project that git was designed for. Like, uh, the Linux kernel, for example. (Or any other projects with hundreds of people working concurently and without any kind of guidance on whatever piece of source they feel like working on.)

I also hate it that there apparently are hordes of git evangelists just waiting to jump at every mention of SVN so they can "benevolently" recommend using git instead, it as if using SVN was some sign of being mentally handicapped.

If anything gets me as aggro'ed as GPL being the "one and only" OpenSource licence these days, it's this mindless push for Linus' latest toy.

Bottom line, I opted for SVN in full awareness of available alternatives, and git won't solve any version control problems for me, because I don't have any.

[Kevin]

This wasn't even directed to you, but to rdos, who has a problem for which a DVCS might be a solution. I know that you wouldn't touch git, hg etc. with a ten-foot pole, but that doesn't mean that rdos has the same irrational hate against this kind of tools.

[Solar]

...irrational hate...

No, it is very rational, in part fueled by comments like that one.

[rdos]

This wasn't even directed to you, but to rdos, who has a problem for which a DVCS might be a solution. I know that you wouldn't touch git, hg etc. with a ten-foot pole, but that doesn't mean that rdos has the same irrational hate against this kind of tools.

Nah, moving between version control systems is no fun. I think SVN is good enough for what I need, and I simply haven't done full repository backup because I don't find it necesary. The web hotel keeps full backup. I've had one incident where they (out of error probably) deleted all my files, but they came up again from a backup, so I know their backup system is working. Especially since I lost a few revisions in this process, which is no hit with SVN.

[Kevin]

No, it is very rational, in part fueled by comments like that one.

IMHO, hate against tools that is fueled by comments is irrational by definition. (I also consider my own dislike of hg mostly irrational, it's just not the right thing for me - but being aware of this I usually don't tell the whole world that I hate it)

Nah, moving between version control systems is no fun.

Well, it depends on how well the import/export is working. For SVN repos it's usually working very well. In fact, I've even been using git-svn just as a better SVN client occasionally.

But then, if the discussion about backups was only theoretical and you don't have a reason to actually have them, not changing anything is the best solution, obviously.

[Solar]

IMHO, hate against tools that is fueled by comments is irrational by definition.

In part fueled by the comments of git evangelists. It is a sad, sad fact that every thread in on the 'net that talks about SVN in any way, however tangential, will get at least one post stating that "try git, it's so much better".

As a SVN user, you have two options at that point:

1) Ignoring the post, leaving the statement "try git, it's better" stand unopposed.

2) Reacting to the post, at which point the git evangelist will act nonchalant and make fun of the SVN user(s) "becoming defensive" and "being irrational".

It's very, very irritating either way, and part of an overall attitude problem of the git community in general. Yes, git does have advantages over SVN, but it has its share of disadvantages too. Do you see SVN users jumping all over the 'net posting in git threads?

As I said, there are other reasons, too: Documentation, complexity, learning curve, workflow, tool integration, access control. There are more which can't be shrunk into simple bullet points.

But I've gone down the road 2) too far already. I'll just leave it up to you to annoy me further re 1).