Anyone still using SVN?

What’s wrong with svn ?

🍿

@vane That it's not Git I guess.

That’s what I used professionally. It worked out very well and I never had any issues.

git commit -am "izi"

Wrong tag
@Fast-Nop 👀👀

@vane Something as simple as branching and merging is a massive PITA, there's no support to rewrite history (therefore no squash and merge, no rebase, etc.), it's centralised, you can't commit without also pushing your changes, etc.

It was fine for the mid 2000s, but we've moved on. Git does everything SVN can and much, much more.

The first version control system I used was Dropbox

(I was 14)

We're using it in our company because it's centralised, doesn't allow history rewriting, you can't commit without also pushing, plus that branching and merging aren't much of a problem.

It's also not as fucked up as git because the only metaphor SVN uses is a file explorer. We don't have time to toy around with a massive overkill and error-prone VCS just because the Linux kernel uses it.

@UnknownError235 It's better than nothing. I understand that a proper VCS can be quite overwhelming for someone new to software development (with everything else that's new to you and probably with no one to help).

@Fast-Nop Pfff Git is super simple.

Branches are just n-dimensional membranes, mapping the spatial loci of successive commits onto the projected manifold of each cloned repository, and commits map to isomorphic contours in source-code phase-space.

http://web.archive.org/web/...

Why don't people get this?

@bittersweet You know you have a fucked up architecture when explaining the usage requires explaining the implementation.

We had that state of affairs with cars, too - but that was with early prototype versions where starting the car would take half an hour and fiddling around with many levers and settings.

@Fast-Nop I think git actually makes a lot of sense.

Although I wish Darcs and Git had a baby. In Darcs, "commits" are more like free-floating diffs without solid history, where pull acts like a regex cherrypick, so branches emerge more naturally based on needs.

You'd say "give me all diffs which look like hotfixes, and all diffs for this feature, but I don't care about documentation diffs" — It's kind of "fuck timelines and branches, imma pick whatever I want!".

But Git has some amazing consistency properties, where everything is always recorded and safe and reversable (when using only safe non-history fuckup commands)

So I basically wish Darcs had some kind of history-preservating snapshotting on top of it's "cherry pick all the diffs" methodology.

@bittersweet git's underlying tech is really good. However, it fails to abstract that tech. There is no porcelain, everything is just plumbing. Ironically, considering Torvald's rants, git is the C++ of the VCS domain.

@Fast-Nop That's true. It does follow the Unix philosophy internally by having commands do one discrete thing, they could have been a bit more opinionated and built an interface around a common workflow.

Most of the time, people don't care about the difference between git add and git commit, so that's often being aliased into one command.

My most used alias is "qp 'some description' ", quickpush, which just resyncs with remote master, takes the current local working tree changes on the master branch, splits off to a new branch named after slugged description, git-adds everything, commits, pushes to remote, creates a PR if GitHub CLI exists, and switches back to master.

It's my "I'm fixing bugs don't bother me with git crap" alias.

Never used SVN. Sounds quite nice to be simple and bound to a server, but also limiting.

For example: Many of my projects start completely offline. I usually only push/uploae them when I think they're at least worth a bit.

Rewriting the history is not a problem bit a feature. Many servers block such changes to the default branch by default, or e.g. GitHub warns in PRs (and thus keeps potentially lost changes accessible anyways).

I also really like to rewrite the history in the sense that I change my new few and not yet pushed commits.
Did one thing, the another and found a 2 line change for the first thing? Just rebase and fixup the temporary third commit to the first. When I'm done for the day, I can push my commits which are a lot cleaner this way.

As far as I understood from SVN, the above wouldn't be possible. I would have needed to pollute my changes with quick fixes or, to prevent the issue in the first place, just send multiple changes at once with not distinction.

From this conversation i am realizing my company is trying to make git work like SVN by making us use a "tool/script" which adds, commits and pushes in a go.. and the script is crappy in the way that if i type the wrong password for push.. i have no other way to push it again except to revert changes and do it all over again.

Can't be mocked for using SVN if you just commit directly to production via FTP.