> Edward, can you give us a short overview on the state of your
> version control project?
>
> Are you currently using a version control system (which one?)?
> Are you planning to switch to svn or are you evaluating svn
> to introduce version control? Or are you using svn in
> production and encountered servere problems in your workflow?
> If least, please give an example.
> What kind of files are you dealing with?
> How many people are accessing these files r/w and r/o?
I am an IT contractor. I generally work for small companies (less than
50 people each, with all repositories on one server) that do various
kinds of hardware & software design, which means they've got a wide
variety of file types for revisioning. Sometimes source code, sometimes
documentation, sometimes binary files.
I started with rcs some years ago, then cvs, and wincvs, and
tortoisecvs, and svn, and tortoisesvn.
I first evaluated svn & tortoisesvn a little over a year ago, but didn't
start using it regularly until september, with purely linux svn.
Started using tortoisesvn regularly a couple months later.
I have had svn in production since that time, and the engineers and I
find it infinitely superior to the other other systems we've used in the
past. Mostly because you can add/remove/rename a file in a way that
makes sense (unlike cvs), and you can obtain file locks (unlike cvs).
Previously cvs was the best I'd found.
So the short answer is, no, we are not encountering any severe problems
in workflow.
In fact, I never felt the need to go browse this email list until
recently, when the vp of engineering for one of the companies thought he
uncovered a bug. When he locked a file, and someone else did an update
or checkout, it did not appear on their system with a lock. The other
people were able to ignorantly go modify the file, and never find out
the file is locked until they try to commit, and all their time was
wasted. As I researched the "problem," I discovered this has been in
discussion many times before, and that it was actually behavior by
design.
The basic problem is -- if someone locks a file, there's no indication
to another user that the file is locked, unless he/she manually checks
for lock. Therefore in the present design, people are forced to
habitually check for lock on every file they edit, or run the risk of
having to merge conflicts afterward. I know nobody will habitually
check, because 99% of the time there will be no lock. And the end
result is people have to merge conflicts when they happen.
I feel this design is worthy of at least an optional change of behavior.
Why force people to manually do something if it can be done
automatically. That's what computers are for.
If there were an option to change this behavior - if one person's
tortoisesvn would change the icon of a file because someone else has
locked it, then tortoisesvn really provides more than just revision
control. It's a communication and collaboration system, and more useful
than the present design. But people should always be able to not-use
that feature as they wish, because it's not always appropriate.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Tue Apr 25 17:59:00 2006