Hi Wolfgang,
2008/7/29 wbaron <Wolfgang_Baron_at_gmx.de>
> Hi Andy,
>
> On 28 Jul., 17:06, "Andy Levy" <andy.l..._at_gmail.com> wrote:
> > On Mon, Jul 28, 2008 at 10:46, wbaron <Wolfgang_Ba..._at_gmx.de> wrote:
> > > Overlay icons, properties and "check for modifications" only show the
> > > local lock status of files. That's ok, if you share your woking
> > > directory among all users, but not, if you use a server. Not instantly
> > > seeing the lock status will cause frustration in the team, because
> > > things are never what they seem to be.
> >
> > > The only way to really see locks, is to "check for modifications" and
> > > then click on "Check repository". The locking information, which is
> > > displayed there is the one you want to see all the time, so that's the
> > > information, which should be updated, whenever the local status is
> > > being refreshed. I know this slows down display a bit, but that could
> > > be minimized by the cache.
> >
> > The base Subversion libraries do not cache lock information. It really
> > isn't a good thing to attempt to cache, and it would slow things down
> > a lot more than you think. What happens on a slow network connection?
> > Or working offline entirely?
>
> That's why I suggested timeout in both directions. If the user
> requests the information in a high frequency, he is willing to wait
> and the other timeout prevents things to slow down too much. As
> TSVNCache is a process with man threads anyway, you would never have
> to wait, but let the information be kept current in the background.
>
The key to team development is communication. If your team members
individually start locking files without any clue what the others are doing,
then you have a bigger problem than getting them to accept SVN.
Use the svn:needs-lock property on files that need to be modified by a
single developer at a time.
Make sure your team understands why these files are made read-only by SVN
until a developer acquires a lock on them
Then educate them to update their Working Copy prior to attempting to
acquire locks. And let them use the 'Check for Modifications' dialog to find
out who has locked the file.
Let that soak for 3 months and then let the team evaluate SVN usage.
<snip>
>
> I am the one that has to bring SVN to my team and I am having trouble
> finding acceptance for this shortcoming (we used VSS until now (yeah,
> yuck, sorry for that bad word, but that's the way it was and I am
> trying to change that)).
>
The biggest change the developers have to go through is the notion that they
do not need exclusive rights on a whole bunch of files to make significant
changes. They need to get used to doing regular updates and commits. Large
modifications need to be done on a branch and later merged to trunk
(allowing potentially conflicting small changes to pass through until it is
time to merge the larger changes back into trunk).
Again, team work is key here, because the only way to prevent lots of
conflicts is to ensure developers are handed work packages that do not
interfere.
<snip>
Am I reaching any developers here that might include this very nice
> feature into a future release or is this the wrong place to post?
> Andy, are you a TortoiseSVN developer?
>
Developers are also reading this list. However, TortioseSVN relies on the
subervsion libraries for its features. And the nature of subversion is to
minimise the need for server-round trips. Chances of getting support for a
frequent server request on lock status are slim I guess.
--
Regards,
Jean-Marc
----------------
___
// \\ @@ "De Chelonian Mobile"
/ \_/ \/._) TortoiseSVN
<\_/_\_/ / The coolest Interface to (Sub)Version Control
/_/ \_\ Check out http://tortoisesvn.net
Received on 2008-07-29 22:37:06 CEST