Saturday 21 June 2008 — This is over 16 years old. Be careful.
Subversion 1.5 has just been released, but it does nothing to fix what I consider to be Subversion’s biggest hole. I know people deride svn for not being distributed, or for doing a bad job of merging, and both of those will be solved when everyone finally switches over to git, as I’m sure we all will eventually.
But I don’t miss those things. The thing I miss that Subversion is lacking is a repository setting for globally ignored files. You can set a property on a directory to ignore (for example) *.pyc files. And you can set your client to always ignore *.pyc files in any working tree on your machine. But there is no way to set a repository to ignore *.pyc files anywhere they appear in the tree.
This is such a common need in software development, and is truly a property of the repository, not the client. Why are we still either touching every directory in the tree, or touching every client on the team?
And probably this will also be solved when we all switch over to git...
Comments
Anyway, from SVN 1.5 on, *.pyc is already included in global ignore files.
Besides, neither Git nor distributed version control systems are not the solution to everything:
"It is clearly true that if you're in a tighten control corporate environment, centralized systems work better".
Who said that? Me? No. It was said by our "modest" leader Linus Tovard during a presentation at Google in 2007.
I was being only a bit tongue-in-cheek with the Git references. I think it will be widely adopted, but subversion also has a long future ahead of it. I've watched Linus' presentation, and unfortunately couldn't take much of it seriously. The actual content would fit in about ten minutes, the rest was just him making clumsy jokes about other systems and developers.
Anyway, you may as well forget it, I'd say, since we have the precious simplicity of Mercurial (and Bazaar-NG too).
It actually saddens me a bit, seeing many Pythonistas flocking to complicated tools, when the pythonic ones, within and without, are readily available.
But then, the simple way is not always easy to follow. And no amount of joking is going to make it easier.
Search for "global-ignores"
When new developers join my team, we have to manually ensure that their global-ignores setting is correct for the repository. This is precisely the thing I am complaining about.
You're coming over overly defensive to me, with partisanism leaking through in the "fairly confusing".
IMO Ned's post was less one-sided than your comment.
If you feel so strongly about this, why not just submit it as a feature request to the subversion project?
http://subversion.tigris.org/bugs.html
This is one of the benefits of an open-source project...it's an open community.
Maybe what needs to be done is a silent recursive for properties instead of only focusing on the ignore feature itself. Something like svnglobal:ignore or svnglobal:*. Any directories or files further down inherit these properties from the level above.
Or maybe properties should just be recursive all the time. If they are overwritten on a lower folder, then they are overwritten for that level. That would make a lot more sense to me.
Actually, the problem is not only the global-ignore; the svn:ignore handles this just fine. The problem I see is related to auto-props:
"The auto-props section controls the Subversion client's ability to automatically set properties on files when they are added or imported."
It would be nice if there were a config section at repository level where we could set ignores and auto-props at repository level. This would be much simpler than try to do the same through a hook.
I searched in Subversion bug database and didn't found any related issue. Now, I will suggest this at svn mailing list.
Regarding your comment that it is a feature of the repository and not the client, that really depends on what side of the fence you stand on. I could argue that the repository should store whatever files are sent to it - you're arguing that it shouldn't.
From a personal stand point, I don't find the client side configuration such a problem - however I also don't need to check out lots of different repositories all the time. Out of interest, what are you doing that makes the client side setting such a pain?
Al.
One of the main benefits of client-server architectures, in this case using a central repository for version control, is that the single server can enforce rules rather than relying on the goodwill of fallible and possibly hostile clients.
Any choice that favors the clients over the server, such as promising to accept and store any file from clients rather than reserving the right to ignore them, undermines this important strength of the central server model; when a project doesn't want silly files in its repository, hoping that everyone uses a suitably configured client at all times is strictly worse that setting a rule once, in one place, and knowing that it will be respected whatever the users do.
@Lorenzo: excellent point.
And while were at it, I have not found a way to specify any svn:ignore rules when importing a project into SVN. With CVS, you can just put .cvsignore files in place, but with SVN, you have to remove any files you don't want to import first, then do the import and then copy them back. Very cumbersome. :-(
You don't know about them till You're used to work without them and then forced to switch back on some projects.
Ideally Subversion would have repository-based config, I agree. However, you could use a pre-commit hook to prevent people from checking in CRLF files.
Regarding ignores-on-import: Your ~/.subversion/config should be able to do this. See there for details. (You may want to move that dir aside and re-run 'svn', so the dir will be recreated and then you can see the latest template.)
It may not be Subversion's biggest problem, but I think it's not as easily solved as you imply. First of all, getting every developer to run any kind of one-time setup script is always going to be a problem. Second, you don't address how the list of global ignores (or mime-types, or whatever) is to be updated, which it will surely need to be from time to time. Third, you might be assuming homogenous client environments, but that is rarely a reality. Fourth, what if the developers already have their own ignore-configuration set up -- now the script has to be smart enough to merge, rather than overwrite.
The solutions to this are not simple; that's why it comes up over and over and over in our user forums.
In Git there are local, per repository ignore file `.git/info/excludes` and `.gitignore` file in working directory, which can be comitted and therefore applies to all clones of given repository; equivalent of server-side settings in Subversion, IIRC.
Now patterns in `.gitignore` applies *RECURSIVELY* to the directory the `.gitignore` file is in and all its subdirectories... unless pattern contains slash '/' (for example begins with '/'), then it is "anchored" and must match non-recursively.
See gitignore(5)
#!/bin/tcsh -f
/usr/bin/svn --config-dir=globalconfigdir $argv
That's still a client-side solution, and anyway, why would someone do that rather than just set it in their ~/.subversion/ config area? (I think the days of multiple developers running their client-side processes on the same machine are mostly gone -- perhaps your dev environment is an exception?)
I want all of the developers to use the same config so that I can set ignores and auto-props globally. By using the wrapper I can set --config-dir to a global config file. If we used ~/.subversion I would need to get all the developers to create, update, and maintain their ~/.subversion/config files ... I would prefer to set on the server side but I think that hole is still there...
Add a comment: