@Dan
I only refer to Lock/Unlock as that is what was being mentioned in the answers above. Actually it is Check In/Out, I dont know any system that uses exclusive Lock/Unlock so perhaps it is a bad term.
If multiple people cannot edit the same file simultaneously, it's a lock. If you "check out" reallyimportantfile.c and go home for the day, no one else can edit that file. This is a lock, and it's horribly brittle.
You also still have the problem where concurrent changes can conflict. E.g. You edit A to add a call to a function in B, while I edit B to rename/remove that function. We still have to merge. The only difference is that VSS doesn't understand merges at all, and has much worse granularity.
Why, we have many projects and many components. Things like String, Array, Map and many hundred other classes and Reusable components that dont get edited often ... do you mean that you edit every file in every project throughout your entire company on a daily basis, I find that hard to believe.
You shouldn't be sitting around using old versions of code. That's why SVN provides update functionality. If you keep an old version of Map on your computer long enough, someone is going to edit the source without you knowing. You're then going to commit some change that works on your machine but not on the build machine (which has the latest version of Map).
And for the record, no I don't edit every file every day, but I do update them every day.
Its potentially too late then isnt it, you have potentially committed a broken file. What you should always do is get/commit/merge to ensure you havent broken the project .. with the commit/merge model its more hidden away to do this.
No, because SVN won't commit if it detects a conflict. It's not really commit/merge. It's merge/commit. Even if you don't manually update your code first, SVN will still merge before committing. It will not let you commit if there's a conflict.
I don't have any real experience with VSS, but the way you are describing it, it sounds as if you have to check out (or manually update) Map to get the updated version. This means that it's extremely easy for your code to get out of sync with the repository.
The other way to read your description is that every time you checkout code, it does a full update. In that case, it sounds like either 1) no one else can edit anything at all or 2) no one else can safely edit anything at all. If it stops everyone else from touching the code base, then it's a full lock and completely useless. If it doesn't, then you don't have any kind of concurrent modification protection (because someone can edit Map after you check it out).
I agree that is what should happen, and it should be built it, IMO it should be forced to do this ... ie. you cant commit without doing an update first. But it doesnt enforce it and doesnt give you the implication that it is necessary and thus its potentially a problem.
A merge always happens when you commit. If you try to commit a file that someone has modified since your last update, SVN will force you to perform an update before it will even commit.
Real life issues and problems fyi. I didnt say it scambles the file did I, maybe I missed that somewhere. I did say that it can lead to 'tricky merges' that you could happily do without, something that could have taken a few seconds or minutes can take much, much longer due to merge problems.
The only way you can get into merge conflicts with a single HTML file is if multiple people simultaneously edit it. The VSS approach is to simply refuse to allow anyone else to edit the file. I fail to see how this is an improvement.
Personally, I HATE merging, I detest it, the interface in doing so is problematic in the tools I have used and I avoid it at all costs as it wastes so much time unless it is a straight forward merge. But if you have several people working on the same files its a problem, perhaps you have not experienced it, perhaps you are lucky and I am not, but its a problem that surely you cant deny that I am having.
I hate complicated merges as well. However, if the alternative is to completely lock the file, I'd rather deal with merging. The alternative is to twiddle my thumbs waiting for someone else to unlock the file. (Which can stop me from editing other files as well if there are dependencies.)
Why on earth would that be an abuse. I want to source control my documents and my graphics because I want a history of changes, why would this possibly be an abuse. Do you mean to say you only source control text files? That seems strange and unlikely in most situations and perhaps you are not using Source Control in the way it should be.
I'm not sure how you made the leap to text-only. My point is that if you have to lock everything, you give up way too much of the versioning power. The ability to edit simultaneously is vital for any large effort. Frankly, I think it's almost vital for small efforts.
And again, on the rare occasion that it's necessary to lock a file, that's still possible. It just shouldn't be the standard mode of operation.
Perhaps, but thats irrelevant. I asked for answers and comments to my observations be they right or wrong and I dont care to be denigrated for daring to question the absolute perfection of Subversion.
It's not irrelevant and I didn't "denigrate" you. I'm giving you some pretty strong evidence that your observations are flawed. If most software is maintained in SVN-style repositories, isn't it possible that the merge/commit style works pretty well?
And no one said SVN is perfect. Don't get snarky just because I disagree with you.