Re: Re: Concurrent versioning = spawn of the devil?

> > Tell us what arguments he uses. Odds are that his opposition
> > stems from a misunderstanding.
>
> He simply says that concurrent versioning is too dangerous, merging
> is too difficult and too much subject to error.

Multitudes of developers world-wide, working on thousands of projects, would no doubt disagree. However, this sounds more like "I don't know how to do concurrent versioning and merging, and I don't want to know" than an informed opinion based on experience with both systems.

If he thinks the TortoiseSVN diff/merge utility is too difficult to use, then I don't knwo what he *would* consider easy. That's one of the niftiest tools of it's kinds I've seen, especially at the price!

> He says that we are exposing our clients to too much risk if we
> subject their code to that kind of an environment.

Without robust development practices, such as regularly run programmer, integration and acceptance tests, both schemes are risky.

> It's not helping that we can't see when a file is locked until we try
> to check it in. I know ... the answer is "don't lock the damn thing"
> ... but that falls on deaf ears, I get "I'm not checking ANYTHING out
> unless I can lock it and keep all you jabronis out of it!".

That sounds like a control [freak] issue, not a risk assessment.

> I will have to revisit TortoiseSVN and see if I can get that to
> work... the problem there is that it doesn't remember my login name
> and password and so I have to enter my password just about every time

I suggest asking on the TSVN list; someone there might be able to guide you in the right direction. FWIW, TSVN remembers my credentials just fine; we're using LDAP authentication to an Apache hosted repository running on some distro of Linux, I think it's Red Hat EL 4, but I'm not sure.

I can't give you any links to arguments, other than the ones others have provided, but I can give you our experience in moving from PVCS. We had originally chosen PVCS over VSS because of the problems experienced by other users, as well as some evaluation done by our own folks. Given that even Microsoft never used it, we didn't figure it suited us either.

The move from Lock-Modify-Unlock to Copy-Modify-Merge went largely unnoticed, except by those of us who were continuously having to unlock stuff that was left locked by developers on vacation or some such. Simultaneous editing of files in the same branch just doesn't happen all that often, and when it does, it's usually just a matter of a lack of communication.

Merging of branches back to trunk is simple using even the command line interface; with Tortoise, it's ridiculously so. The merge tool in PVCS was, admittedly, pretty good, but TortoiseMerge still beats it, and both of them were far better than the VSS one.

Note that the Lock-Modify-Unlock pattern isn't *always* bad. Used with binary, or otherwise un-mergeable, files, such as some word processing documents or spreadsheets, it can help prevent a lot of wasted effort.

Brad

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 8 16:39:25 2006