On projects and their goals

Posted Apr 7, 2010 0:13 UTC (Wed) by dlang (guest, #313)
In reply to: On projects and their goals by iabervon
Parent article: On projects and their goals

quote: Allow a user to prepare a commit that includes some directories without disclosing the contents of those directories to the user (where the user leaves them unchanged relative to some commit).

explain this a bit more please.

deferring downloading of some files can be done with git narrow/shallow clone options

as for this one:
Support users communicating with each other the intent to change a particular unmergeable file in a particular branch of a particular repository such that a user can be sure that it will be unnecessary to resolve merge conflicts in order to push changes to that branch of that repository. (And other users may make changes to these files, but will not be unaware that they may be forced to redo their work because of a conflict.)

how does SVN do this? isn't all the communication between users done outside of SVN? or are you referring to locking when you check something out?

your next point: There's also the issue that, if a project has an enormous SVN installation already, such that reading the whole thing is impractically slow, DVCSes currently don't support only importing (and reading) the portion necessary for some particular operations.

has nothing to do with SVN being better, merely with it being painful to switch away from SVN

re: large binary files, how large does SNV support? I thought I saw comments here indicating that it also has a fairly small limit.

On projects and their goals

Posted Apr 7, 2010 2:04 UTC (Wed) by iabervon (subscriber, #722) [Link] (6 responses)

First one: there are projects that want to have some files that some users can't read in the same directory as other files that the user can modify (and make commits to change). SVN doesn't need the user to be able to read all of the files in a revision in order to create the revision, simply because the client side doesn't need the information and the server side has it. Git (for example) could deal with this, but gets upset about not having access to all of the content in the commit.

Second: Last I checked, git's shallow clone support wasn't sufficient to let you get the arbitrary set of blobs that you actually care about, and there's only narrow checkout, not narrow clone. Furthermore, you can't clone the whole history, figure out (from the commit messages and changed files) which blobs matter to you, and download those particular blobs.

Third: Locking. As I just mentioned in http://lwn.net/Articles/382416/, there are situations where development tasks can't be parallelized with the available tools, and users want to avoid wasting their times by getting (advisory) locks and making sure that the user who got the lock doesn't have to redo their work. SVN offers mandatory locks, which is not optimal for users that choose to ignore them, but better than doing pointless work accidentally.

Fourth: I didn't say that other systems weren't better than SVN. I said that there were things that other systems didn't deal with as well as SVN does. One of these is your existing SVN server being unable to produce the whole history in a timely fashion.

Re file size: I've never stored a large file in SVN, but I've heard of people trying to switch to git and having problems, and it turning out that what they were version-controlling was video recordings that they were editing, and they had a many-TB fileserver and a laptop that could store maybe three copies of the video. I think it was SVN that they were using, but I may be mixing up stories.

On projects and their goals

Posted Apr 7, 2010 20:06 UTC (Wed) by vonbrand (subscriber, #4458) [Link] (5 responses)

Re: "Unreadable files": I just fail to see the point. If I develop, I need to see what I'm working with. Else, I don't need it, and shouldn't have to include it in my commits.

Re: "Shallow clone in git": Right, git is designed to work having all history available. Disk space is cheap nowadays... if it becomes a real problem, it could be ~~kludg~~worked around, I suppose. Not a show killer to me.

Re: "Locking": Sorry, but this is needed in SVN because there is a central repository (lest you lose all version control). With a DVCS, each one works in her own space, and integration (and conflict resolution, etc) don't need to happen during development.

On the others, I'm unable to comment.

On projects and their goals

Posted Apr 7, 2010 20:23 UTC (Wed) by njs (subscriber, #40338) [Link] (2 responses)

Yes, sure, we all know that most people on LWN don't need these features, that's why git is so successful :-). But all that's being claimed is that other people -- not you -- do. Is that really so unbelievable? :-)

BTW, I used to scoff at locking too, but it actually does make sense for files where merging is simply not possible. (Think PNGs, or, like, CAD documents with an undocumented format and no vendor-provided merge tool.) Any simultaneous development requires you to throw away one side and re-do that work from scratch, so delaying integration is a terrible idea.

On projects and their goals

Posted Apr 8, 2010 16:24 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (1 responses)

I do know my set of requirements isn't the same as everybody else's, that is precisely why I'm asking.

What I'm trying to say is that such coordination among developers can't be just done by the tool: If we both start work on some unmergeable file, and then you lock it, I won't become aware of that until I try to lock it myself (perhaps much later, after much work has been wasted). This has to be handled in some other way, AFAICS.

On projects and their goals

Posted Apr 8, 2010 17:10 UTC (Thu) by farnz (subscriber, #17727) [Link]

Normally, the tool support for locking is good enough; working copies of files that need locking are read-only, so that when you come to save, the underlying OS says "no, file is read-only". You then get the lock before you continue working.

What's more, most tools don't even let you start work before you make the file in your working copy read-write. Because it's part of your working copy, your training makes you do that via the version control tool, which grabs the lock for you. Thus, normally it's a matter of seconds between opening a file with intent to work on it, and the tool telling you that you've forgotten a workflow step.

On projects and their goals

Posted Apr 8, 2010 16:44 UTC (Thu) by jschrod (subscriber, #1646) [Link] (1 responses)

You should not that version control systems are used for more purposes than software development. These other use cases have constraints that make your counterpoints invalid; for them you *need* support of processes that include locks, or unreadable files.

On projects and their goals

Posted Apr 12, 2010 1:05 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

Yes, I'm interested in uses other than "software development". But just stating that there are applications that require some strange features doesn't help understanding if they are really needed, just an artifact of the tool currently being used, or even "that's how we are used to do it since way back when".