dotSoftwaredotDevelopmentdotCustomersdotAbout us
PushOk logoblank
bullet Home
bullet My software
bullet Support
bullet My payments
bullet My info
bullet Subscriptions
bullet Voting
bullet Contact us
fast linksFast Links
news&eventsnews and events

2012-12-21 
Major update of SVNCOM version 1.7.2 are finaly released

2012-12-21 
Major update of SVN SCC plug-in - versions 1.7.2 are finaly released

Lightweight embedded Node.js database with MongoDB API.

Ticket

Search go
PushOk Logo blank
leftTicketright

RWMon not locking files correctly

( SVNSCC , VS .NET, RC4, WIN 2000/XP  )
Type: Public Status:Closed Created: 27 Mar 06 03:00 Updated: 27 Mar 06 03:00
--> Tristan Bates (user)  at 27 Mar 06 03:00 writes

Ok, thank you for the information. That's good information to know and
useful for me.

Yes the problem was that I retrieved my source directory via Tortoise and
not as a checkout using Visual Studio. So the source files were originally
R/W (the tortoise default). By checking out as I should using Visual
Studio, the files are in the correct state.
--> Igor Pushkov (admin)  at 27 Mar 06 03:00 writes

For you case you need to re-pull sources completely, not only delete
them. Or set RO attribute by hands and then it will work as expected.
Some explanation about monitor logic, if you find this interesting...
When you didn't issue 'lock' command there are no chance statically
determine should the RO flag set or not. We trying to determine this
in runtime by checking version changing in entries file and modification
in file. So, when version in entries is changed this is subject to
adjust RO flag. The following scenarios are possible:
1. File just appears in working copy. We not know its previous version
(because
it does not exist) and set RO flag on.
2. File already on disk and version in entries is changed. This may be
commit or update operation. How we trying to find which is right:
a. File is marked as checked-out using "svn-lock" or check-out from
IDE (placed into .svn/pushok.svnscc). Then it is update, don't touch
RO.
b. File is not marked as checked-out
... then this is commit if file not changed in last 5 sec, set RO
... or update if it does, don't touch RO
As usual there some trick, if you change file and make commit in 5 sec
monitor consider this as an update and will not change RO. However
this seems to occurs very seldom in normal work.
Also, looking onto above description it is clear that RO file is set
when:
1. File just appears on disk and it is not exists in entries before
this. This is clear pulling from SVN or appearing of new file.
2. When commit detected
--> Tristan Bates (user)  at 27 Mar 06 03:00 writes

There is still a problem with the RWMon.

I have it configured to "not monitor" unspecified folders. Then I mark the
root of my source tree with the pushok:rwmon=check-tree svn attribute.

When I do a "Cleanup and Restart" the cache file correctly contains
"check-tree" for all folders under my source root.

I have confirmed that my source tree is marked as check-tree in the cache.
If I do an update with tortoise or even delete a file then update with
tortoise, it's not setting the RO status on the file. Strangely, some files
are getting set correctly, but my .cs source files aren't.

When I do the tortoise update, the debug.log is saying that the dierctory
is known as monitored and "scheduled examination" of the directory but the
RO flags aren't changing.

For example, I deleted a source file in the Tpg.Ebe.Web folder using
windows explorer, then did a tortoise update (which restored the file) and
got the following debug.log file entries (but the RO flag was not set):

:287024314: + folder (C:\svnroot\GV\Trunk\Source\Viewpoint\Presentation
Layer\UI Components\Tpg.Ebe.Web\) known as monitored
:287024314: + scheduled examination of:
C:\svnroot\GV\Trunk\Source\Viewpoint\Presentation Layer\UI
Components\Tpg.Ebe.Web\.svn\entries
:287024835: + examining changes for:
C:\svnroot\GV\Trunk\Source\Viewpoint\Presentation Layer\UI
Components\Tpg.Ebe.Web\.svn\entries
:287024835: + system is: SVN

Rate this ticket:
Not useful at all
Partially useful
Useful
Very useful



You are 9536316 visitor since 20 Jan 2003.
874 visitors today and 2 online right now.
blank left to top right blank

© Copyright by PushOk Software, 2003-2024, webmaster@pushok.com