I spent yesterday cursing subversion too. My clients all seem to hang, and if I try the command line it refuses to work because the clients have upgraded the working copy with metadata which is too recent, and if I switch clients then they don't work with another subversion repo I need to connect to, and .... ugh.
And if I need to move files I need to delete them and recreate them and lose all my change history because it's too rubbish to have the notion of file moves and ... stupid system.
Ah, true. Whenever I'd googled for it before the answer that had come up was 'try svn add followed by svn delete!' which was not exactly what I'd hoped for.
And the clients I've used don't have the support for it either - which is an issue with the clients, not the system, but then at some point you need decent clients. I'll do many things on the command line, but 'svn add' for complicated project structures with lots of generated resources isn't one of them.
I agree with you on the automated tool creating mayhem in repositories. The advantage of the GUI clients - when they actually have the right feature set and don't hang the IDE or get into knots about what versions they support and where their libraries are - is that they allow users to see, really clearly and visually, what they're doing to the repository. A similar level of control definitely isn't possible with a combination of recursive add and svn:ignore. It's arguably possible with something like find and xargs, but that's putting the entry bar pretty high for a shared project. I figure source control should be a bit more idiot-proof than that. The command line should be there, of course, but it shouldn't be the only way, and the command line shouldn't have to be supplemented with mini-scripts in order to do useful things.
I figure source control should be a bit more idiot-proof than that.
Ah... you'll always find an ingenious idiot can muck up any system.
that's putting the entry bar pretty high for a shared project
I guess I'm lucky, our projects are usually two or three people, PhD level and often people who are perfectly happy with CLI over GUI. That's why I get frustrated with people stuck on GUI stuff.
But I do know what you mean actually... some tools which generate loads of resources only some of which should be in the repository and others of which defnitely should not... can be a real problem if the document control does not integrate well in whatever way.
My users were Consultants and got to stay in far better hotels than I could, so they were of course unfit to be trusted with sharp objects.
With SVN though, I never had a squeak out of them. They could mess with files, they could even mess with subdirectories, but they had a trunk to root their projects in and they never got outside of that. They did not mess with overall project structure. Also, if they did need stuff moving, I was enormously helpful to them - it being easier to be nice and helpful up front than it was to sluice out the augean mess afterwards.
The people who gave me grief were the database crew. Illiterate micro$erfs who spent their entire day plotting ways and schemes to fuck up i18n by mangling file encodings (we ran arabic, thai and ukrainian off the same source files). Our policy was simple: UTF-8 everywhere, but you just can't teach a Windows user not to piss in the sinks.
Don't do add & delete (no history), do copy and delete (preserves history). There's a Move command for doing just this.
I use Tortoise a lot, mostly the File Manager add-in, to see what state large numbers of files are in at once (although the cutsey icons are usually long out of date). For actually changing stuff though, it's either the bare command-line, or the command-line client wrapped up in your pick of scripting language.
And if I need to move files I need to delete them and recreate them and lose all my change history because it's too rubbish to have the notion of file moves and ... stupid system.
Reply
svn mv oldfile newfile
(Unless you're moving them between repositiories).
Reply
And the clients I've used don't have the support for it either - which is an issue with the clients, not the system, but then at some point you need decent clients. I'll do many things on the command line, but 'svn add' for complicated project structures with lots of generated resources isn't one of them.
Reply
That's what command line tools like find and xargs are for. I'd certainly trust those more than an automated tool.
Reply
Reply
Ah... you'll always find an ingenious idiot can muck up any system.
that's putting the entry bar pretty high for a shared project
I guess I'm lucky, our projects are usually two or three people, PhD level and often people who are perfectly happy with CLI over GUI. That's why I get frustrated with people stuck on GUI stuff.
Reply
Reply
With SVN though, I never had a squeak out of them. They could mess with files, they could even mess with subdirectories, but they had a trunk to root their projects in and they never got outside of that. They did not mess with overall project structure. Also, if they did need stuff moving, I was enormously helpful to them - it being easier to be nice and helpful up front than it was to sluice out the augean mess afterwards.
The people who gave me grief were the database crew. Illiterate micro$erfs who spent their entire day plotting ways and schemes to fuck up i18n by mangling file encodings (we ran arabic, thai and ukrainian off the same source files). Our policy was simple: UTF-8 everywhere, but you just can't teach a Windows user not to piss in the sinks.
Reply
I use Tortoise a lot, mostly the File Manager add-in, to see what state large numbers of files are in at once (although the cutsey icons are usually long out of date). For actually changing stuff though, it's either the bare command-line, or the command-line client wrapped up in your pick of scripting language.
Reply
Leave a comment