Apache Updates Subversion - SVN 1.14 LTS Released

[Veto]

If I correctly understand you, your point is that when docs are in some non-text format, like odt, docx, etc, one can't easily resolve conflicts.

Exactly!

Well. This doesn't change what I said, that another user may want to edit the document too, and there's no reason to force them not to. If upon saving your version of document it turns out someone changed the remote document, you just rebase you branch on the remote ¯\_(ツ)_/¯

No! That would be wasteful and potentially creating real world conflict... A locked file indicates the file is being edited. It does not mean, that I cannot override the lock. It just means that I have to coordinate my work with someone else, which is necessary anyway, as changes cannot easily be merged.

I do not mention here the obvious fact that version-controlling binary files is hard because you can't see what changed. Instead I just assume that you can do that somehow, e.g. with some hand-crafted utilities and whatnot. Otherwise it's of no use to share it through a control-versioning system because, well, you never know what anyone did to the file except what they wrote in commit message.

Why do I have to hand-craft utilities and whatnot to version control binary files?? Controlling versions is just as important for binary files and not that hard. Merging changes is just one (although powerful!) aspect of version control.

I did not say that.

Fair enough That was more a general (and somewhat frustrated) reply to the general attitude in the thread that "if git does not support it, you don't need it", instead of trying to understand the need. You, at least ask meaningful questions regarding the use case.

I understand the use case is slightly different from distributed software development - although valid and quite common in its own right. You could call it "centralized repository with granular changes" compared to "distributed repositories with monolithic changes".

It might also be something Subversion does slightly better than git, which was the original point of the discussion.

[bug77]

Since you don't know my use case, it is presumptuous of you to tell me, what I need and what I don't need.

I've been using svn for years. I know it doesn't do anything git can't. If you insist you need locking, I'm pretty sure you're either doing something wrong or are bitten by svn's lack of proper branches.
If you feel there's more to the story, fell free to share.

[Hi-Angel]

The use case is using a version control system for managing large amounts of documents. I only want to check out a single document for editing.

So as I said this feature is for managing documentation. I don't think I have anything to add here since you don't seem to be opposing my first point.

Since merging is impossible, I want to be able to lock the files to signal the document is being edited.

If I correctly understand you, your point is that when docs are in some non-text format, like odt, docx, etc, one can't easily resolve conflicts.

Well. This doesn't change what I said, that another user may want to edit the document too, and there's no reason to force them not to. If upon saving your version of document it turns out someone changed the remote document, you just rebase you branch on the remote ¯\_(ツ)_/¯

I do not mention here the obvious fact that version-controlling binary files is hard because you can't see what changed. Instead I just assume that you can do that somehow, e.g. with some hand-crafted utilities and whatnot. Otherwise it's of no use to share it through a control-versioning system because, well, you never know what anyone did to the file except what they wrote in commit message.

However it seems people here know better than me, what I need

I don't know what you need, I'm just replying your points about lack of a few features in git.

or are apologetic with "if git does not support it, you dont need it"...

I did not say that.

[Veto]

Sure you can't. But this is sooo niche usecase that I'd be surprised anyone would be missing it.

The benefits it gives are: taking less space on your FS and transferring less data over the network (well, for the first time at least). Sounds nice, but not until you realize that the only files you can work with in such way are docs. You can't edit code in this fashion because you need at the very least to check the project still builds after your modifications, and for this you gonna need the rest of the files.

Besides, most popular web interfaces over git servers, namely gitlab and github, allow editing files straight from web, so indeed you don't need to even have the project locally if you just wanted to change docs.

Thanks God git has no such feature. If I want/need to work on the file, why should someone stop me from doing this? Besides I can imagine how easily using this feature gonna end up in mess where peoples forget to unlock the file before going to lunch of even home, and nobody can do anything. What legitimate usecase do you even imagine for this "feature"?

The use case is using a version control system for managing large amounts of documents. I only want to check out a single document for editing. Since merging is impossible, I want to be able to lock the files to signal the document is being edited.

However it seems people here know better than me, what I need or are apologetic with "if git does not support it, you dont need it"...

[Veto]

You can't and for a good reason: it's dangerous.

You don't need to lock files when you have proper branches. Locking in svn is just a workaround for painful merges (because, while you don't have branches, you can't rebase either).

Since you don't know my use case, it is presumptuous of you to tell me, what I need and what I don't need.

[F.Ultra]

lmddgtfy

Have you never used a distributed VCS? Everything is local except pushing/pulling. It's much, much faster. Working on branches is nothing special, extremely quick. You can continue to work with it even during network connectivity loss, which has saved my ass a few times.

If those aren't benefits to you, I question whether or not you're actually a software developer.

And as to whether or not "SVN needs to die" -- I don't think it needs to, I just think it will.

I have never had any problems with check-in speed (svn only sends out the diff). Branches have no performance penalty in svn either, nor check outs either (I always do a "svn up *" every morning to fetch all the latest check-ins from the various repos that we have at work and it just takes a few seconds).

Now being able to perform offline revision control would of course be a benefit that I never have thought about before so that is one area where a distributed VCS sounds practical, not sure that this feature alone would sway me to switch from "old familiar" though considering that offline is not something that I've experienced in years. But thanks for being the one person that finally mentioned an actual benefit of a distributed VCS for us that have no need for the other features.

[fuzz]

So please enlighten me how a distributed VCS would increase my productivity.

lmddgtfy

Have you never used a distributed VCS? Everything is local except pushing/pulling. It's much, much faster. Working on branches is nothing special, extremely quick. You can continue to work with it even during network connectivity loss, which has saved my ass a few times.

If those aren't benefits to you, I question whether or not you're actually a software developer.

And as to whether or not "SVN needs to die" -- I don't think it needs to, I just think it will.

[F.Ultra]

Never.

Besides, I was talking about here and now, not about a few years from now.

OK, I'm quite sure that if we spend enough energy we will find some things that Hipsters use/do that happens to be from 2005 just like GIT. The main point was that the age of GIT have zero to do with Hipster or not.

Anyway, I was not trying to paint GIT itself as Hipster, I was just replying to the whole "SVN needs to die because everyone must use a distributed VCS in 2020", that is what I was meaning to call out.

[Vistaus]

just give it a few more years and that 2002 Opel Corsa of yours might be hip again.

Never.

Besides, I was talking about here and now, not about a few years from now.

[bug77]

How do you checkout a single file from a central remote Git repository, work on it and check it back in again - all without copying the repository?

You can't and for a good reason: it's dangerous.

Can you also lock the file, such that others cannot work on it?

You don't need to lock files when you have proper branches. Locking in svn is just a workaround for painful merges (because, while you don't have branches, you can't rebase either).