> -----Original Message-----
> From: Julian Fitzell [mailto:julian@beta4.com]
> Sent: Monday, December 09, 2002 9:00 PM
> To: dev@subversion.tigris.org
> Subject: Re: Is SVN ready for use?
>
>
> Roman Rytov wrote:
> > Actually I didn't practice SVN in the company but there are some of
> > not-technical people here and I wouldn't like to let them even care
> > about merge. They experience problems on much simplier level.
> >
> > What my group (as R&D people) needs is to somehow to recall to take
> > the latest version from a repository. CVS or VSS both have
> > "watch"-like functionality and closely integratable with almost all
> > IDEs (that I'm sure SVN also can). So in these cases it's
> up to an IDE
> > to remind to a developer to chek-out/in a file (actually it obliges
> > her).
> >
> > I have to confess that I rather ask how to organize work then argue
> > about it. I believe SVN in the current stage is workable also but I
> > wanna underatand the whole workflow.
>
> I think the reason you are getting argument is that the general
> philosophy of CVS is not to lock files (even though it provides the
> ability to do so) and the group of people on this list are those you
> like CVS's philosophy enough to want to build a better CVS. We,
> therefore, almost all believe concurrent workflow is more productive.
>
> I also (I'll only speak for myself here though I believe it to be
> general) am very accustomed to hearing people who haven't used
> concurrent version control much make the exact arguments you
> are making.
> Heck, I made the same arguments myself many years ago. But
> in every
> case, once I've convinced someone to try it, they like it and
> don't go back.
>
> It seems to me that forcing users to *always* know that they have to
> lock files, and to *often* have to know how to deal with a
> file that is
> already locked is more complex than having to know how to
> *occasionaly*
> correct a conflict marker. Now obviously this depends on the type of
> files you're storing and obviously it becomes a lot simpler
> to handle if
> you have a good svn client that can walk you through it (I
> don't know if
> any of the visual clients are far enough along to do so... haven't
> looked at them much).
I got the point and definitely I'll try it. Now I see that someone
working at a file without being aware that the file is under concurent
processing risks at most to be resolve the conflict manualy. Not a big
deal especially it's unlikely that they both work on the same lines.
What I don't know is how to enforse programmers to update and commit
their changes on a regular basis. I asked already about "watch" and
because it yet to come I wanna know how people work. Now my team is
working with VSS and a version builder detects whether someone forgot to
check-in files just before building. Unfortunately it happens pretty
frequently. How to prevent forgetting?
Roman
>
> So anyway, I'm not going to try to convince you. And I'm totally
> unaware of the level of support from the core developers for adding
> locking, etc in the future, though I know it has been
> discussed before.
> But I thought I could shed some light on why you are getting the
> response you are.
>
> It's like walking into a room full of Mac developers and
> asking them to
> help you port OSX to an intel machine (yes, I know Apple has
> apparently
> done this but won't release it) - sure, they think it's a
> good idea in
> theory, but they'd rather just convince you to use a Mac. :)
>
> Julian
>
>
> --
> julian@beta4.com
> Beta4 Productions (http://www.beta4.com)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 9 22:46:29 2002