[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Blundered conflict

From: Jan Hendrik <jan.hendrik_at_myrealbox.com>
Date: 2007-01-26 17:13:23 CET

Hi developers/users!

Giving SVN a second try (after dropping it at around ver. 1.0 when a
newly added file either would not commit [without being able to re-
add] or would never turn up in updates, which was just the last
straw in an endless chain of issues) since a few months I am quite
impressed by the gain in stability - no broken repository (Berkeley,
what else), great gain in operational speed, and no serious issues -
till now:

Using TSVN WorkingCopy1 was updated to rev. 1796. For file
"xrates.py" a conflict was reported and the two revision files
"xrates.py.r1792" and "xrates.py.r1796" were generated.

xrates.py had no conflict markers added, however, and looking at
the diff there should not have been a conflict in the first place.
Accordingly the timestamp of xrates.py still dates a couple of days
back. The file was open in SciTE editor, but SciTE does not lock
files, and actually two other files open in SciTE were updated
correctly and accordingly reported by SciTE as modified outside.
Neither was the file locked by SVN's mechanism which was never
used here anyway. Here are the diffs, first between un-updated
xrates.py and xrates.py.r1796:

--- D:/Internet/xrates.py Thu Jan 18 17:20:05 2007
+++ D:/Internet/xrates.py.r1796 Fri Jan 26 13:12:41 2007
@@ -412,7 +412,7 @@
 
 #=============================== [ update_remote ] =================================
 
-def update_remote(remote_host, remote_pwd):
+def update_remote(remote_host):
 
         tn = telnetlib.Telnet()
 
@@ -434,7 +434,7 @@
 
         print tn.read_until(remote_host + "> ")
 
- tn.write('/usr/bin/perl58 ./offscene/xrates_marine.pl\n')
+ tn.write('/usr/bin/perl58 ./offscene/xrates_ext.pl\n')
 
         print tn.read_until(remote_host + "> ")
         tn.write('exit\n')
@@ -602,7 +602,7 @@
         for remote_host in remote_db:
                 upload_xrates(remote_host)
                 if remote_host in telnet_sites: ## remove if telnet available
- update_remote(remote_host, remote_pwd)
+ update_remote(remote_host)
 
 for server in local.keys():
         if local[server]:
@@ -616,15 +616,13 @@
                                 print 'updating exchange rates on %s (%s):' % (server.upper(), host_ip)
                                 if os.path.exists('//%s/%s' % (server, internet_share)):
                                         copy_usrate(usrate_php_var)
- else:
- print 'Cannot write usrate.txt to %s (path/share may not exist)\n' % server.upper()
- dbserver = eval('%s_db' % server.lower())
- for db in dbserver:
- update_local(db)
+ dbserver = eval('%s_db' % server.lower())
+ for db in dbserver:
+ update_local(db)
                         else:
                                 print 'local server "%s" unavailable\n' % server.upper()
                 except:
- print 'Cannot contact local server "%s"\n' % server.upper()
+ print 'Cannot ping local server "%s"\n' % server.upper()
 
 os.unlink(tmpfile)
 
This is ok and except for one all differences are pending
modifications on xrates.py in WC1. Now here the diff between
revs. 1792 + 1796 (this is the thing done and committed from WC2):

--- d:/Internet/xrates.py.r1792 Fri Jan 26 13:12:41 2007
+++ d:/Internet/xrates.py.r1796 Fri Jan 26 13:12:41 2007
@@ -434,7 +434,7 @@
 
         print tn.read_until(remote_host + "> ")
 
- tn.write('/usr/bin/perl58 ./offscene/xrates_marine.pl\n')
+ tn.write('/usr/bin/perl58 ./offscene/xrates_ext.pl\n')
 
         print tn.read_until(remote_host + "> ")
         tn.write('exit\n')

Updating WC3 updated xrates.py correctly with this one
modification above.

Probably related:

- a few weeks ago I noticed that a minor modification in two files I
was quite sure about was missing. Since there was nothing but
my recollection I did not explore the case and just re-did the
editing. If there had been a conflict then it had not been without
conflict markers. That I am sure.

- secondly in an untimely synchronization process the timestamp
of a file was reset to the date/time of before correcting a typo. This
file would not show up for commit in either SVN or TSVN. As it
was just a typo the filesize did not change and now the timestamp
had not changed either for SVN/TSVN. I found no other way but to
deliberately change the timestamp by at least 1 minute plus/minus.

I deliberately work on three WCs on two machines, the repository
is on a third one, all W2K SP4 SRP1. The repository has been
dumped/loaded around rev. 1600 during updating to 1.4.x.
SVN 1.4.2
TSVN 1.4.1 built on SVN 1.4.2

Could someone more knowledgeable explain this or shed some
light on it? Of course I am puzzled about SVN reliabilty and about
how many corpses of lost work I might have collected in the three
WCs already.

TIA (and already for your patience to read to this point),

JH
---------------------------------------
Freedom quote:

     We believed then and now:
     There are no limits to growth and human progress
     when men and women are free to follow their dreams.
     And we were right to believe that.
               -- Ronald Reagan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 31 20:20:13 2007

This is an archived mail posted to the Subversion Users mailing list.