You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Tom Brunet <to...@cs.wisc.edu> on 2004/04/15 18:13:25 UTC
Commits that aren't?
I'm running WinXP and connecting through SSH to a repository on a Redhat
Linux box. I can check out files from the repository just fine. I
commit and it goes through the messages saying I added files, transmits
file data, and I get the message "Committed revision 3.".
The problem is that after this, the actual repository is only at
revision 2, and that commit never occurred at the server, even though my
client told me that it did. Now, my working copy thinks it's at
revision 3, so I can't perform any more commands since the server
apparently doesn't know about revision 3. The only way to recover my
local copy is to checkout a fresh copy (which is at revision 2 without
my changes). Commits done by manually uploading the files to the Linux
box and doing commits on the server work fine.
Is there any reason why my client would tell me that it committed a
revision when in fact it didn't? Why does the client update its state
to a revision that is non-existent? Any suggestions for how to get
these commits to actually happen?
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Commits that aren't?
Posted by Michael W Thelen <th...@cs.utah.edu>.
* Tom Brunet <to...@cs.wisc.edu> [2004-04-15 12:14]:
> Is there any reason why my client would tell me that it committed a
> revision when in fact it didn't? Why does the client update its state
> to a revision that is non-existent? Any suggestions for how to get
> these commits to actually happen?
Are you sure the client is committing to the repository you think it is? What
is the output of 'svn info' when you run it on your working copy? Can you get
information about revision 3 via the client after you commit it, i.e. do 'svn
log' and 'svn diff' show what you would expect?
-- Mike
--
Michael W. Thelen
It is a mistake to think you can solve any major problems just with potatoes.
-- Douglas Adams
Re: Commits that aren't?
Posted by John Peacock <jp...@rowman.com>.
Tom Brunet wrote:
> My best guess is that this basically boils down to an AFS consistency
> problem. Note that in most cases, I've used best-tux.cs.wisc.edu as a
> URL - what I suddenly realized was that this picks the least loaded
> machine at the time of the query to connect to (which apparently changed
> between commands). So all the bizarre behavior, I believe, was because
> I was updating the repository on one machine and AFS wasn't consistent
> when the next command ran on another machine. Perhaps someone else has
> a setup like this that they can verify this behavior?
>
The BerkeleyDB cannot be located on an AFS mount point from multiple machines,
and probably not from a single machine either. I believe someone already posted
a link to the page on www.sleepycat.com which explains this. CVS uses a
file-based repository, so (other than file locking issues), it can utilize a
remote mounted filesystem. Subversion uses BDB, which has specific requirements
which preclude using it like that.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Commits that aren't?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Tom Brunet <to...@cs.wisc.edu> writes:
> My best guess is that this basically boils down to an AFS consistency
> problem.
This from http://www.sleepycat.com/docs/ref/env/remote.html:
"...it is a common error to attempt to create Berkeley DB
environments backed by remote filesystems such as the Network File
System (NFS) or the Andrew File System (AFS)."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Commits that aren't?
Posted by Tom Brunet <to...@cs.wisc.edu>.
> I'm totally baffled. Does server-side inspection of the repository
> (using 'svnadmin' or 'svnlook', running as the proper user of course)
> reveal anything interesting?
I think I figured out part of the cause. I have a bunch of logs here to
show how I came to this conclusion.
My best guess is that this basically boils down to an AFS consistency
problem. Note that in most cases, I've used best-tux.cs.wisc.edu as a
URL - what I suddenly realized was that this picks the least loaded
machine at the time of the query to connect to (which apparently changed
between commands). So all the bizarre behavior, I believe, was because
I was updating the repository on one machine and AFS wasn't consistent
when the next command ran on another machine. Perhaps someone else has
a setup like this that they can verify this behavior?
What still bothers me about this is that the initial commit that started
this all was about an hour before my attempt to check out.. and I've
never noticed propogation issues before, so things must be consistent
relatively fast. We've also used CVS extensively around here and have
never had a problem that I'm aware of. I've even been able to tell
people on the machine next to me to check things out immediately after
checking them in. I'm still somewhat baffled, but I think I've at least
identified a way to safely go about my work.
Anyway, logs....
Tom
** Initial attempt - Convincing myself it's not a windows client problem
tux37(8)% svn co
svn+ssh://best-tux.cs.wisc.edu/u/t/o/tomab/private/subversion/repos/bugrepos
bugwc/
A bugwc/test1.txt
Checked out revision 1.
tux37(9)% cd bugwc
tux37(11)% echo blah >test2.txt
tux37(12)% svn add test2.txt
A test2.txt
tux37(13)% svn commit -m "blah" test2.txt
Adding test2.txt
Transmitting file data .
Committed revision 2.
tux37(14)% svn update
svn: Reference to non-existent revision '2' in filesystem
'/u/t/o/tomab/private/subversion/repos/bugrepos/db'
** It 'looks' like I can commit by ssh'ing to the same machine
tux37(18)% svn co
svn+ssh://tux37.cs.wisc.edu/u/t/o/tomab/private/subversion/repos/bugrepos
bugwc/
A bugwc/test1.txt
Checked out revision 1.
tux37(19)% cd bugwc/
tux37(20)% echo blah > test2.txt
tux37(21)% svn commit -m "blah" test2.txt
svn:
'/afs/cs.wisc.edu/u/t/o/tomab/private/subversion/repos/bugwc/test2.txt'
is not under version control
tux37(22)% svn add test2.txt
A test2.txt
tux37(23)% svn commit -m "blah" test2.txt
Adding test2.txt
Transmitting file data .svn upda
Committed revision 2.
tux37(24)% svn update
At revision 2.
** I attempt to connect to another machine to see if it's a firewall
problem somehow. Notice that the above commit doesn't appear at checkout.
tux37(30)% svn co
svn+ssh://tux33.cs.wisc.edu/u/t/o/tomab/private/subversion/repos/bugrepos
bugwc/
A bugwc/test1.txt
Checked out revision 1.
tux37(31)% cd bugwc
tux37(34)% echo This should not commit >test3.txt
tux37(35)% svn add test3.txt
A test3.txt
tux37(36)% svn commit -m "No dice" test3.txt
Adding test3.txt
Transmitting file data .svn
Committed revision 2.
tux37(37)% svn update
At revision 2.
** Baffled, I try a random machine again. This is where the radar
kicked in. Notice how I check out revision 2, commit revision 2, but..
revision 2 can't update. My guess is three different machines are
being hit.
tux37(50)% svn co
svn+ssh://best-tux.cs.wisc.edu/u/t/o/tomab/private/subversion/repos/bugrepos
bugwc/
A bugwc/test2.txt
A bugwc/test1.txt
Checked out revision 2.
tux37(51)% cd bugwc
tux37(53)% echo Odd >odd.txt
tux37(54)% svn add odd.txt
A odd.txt
tux37(56)% svn -m "odd" commit odd.txt
Adding odd.txt
Transmitting file data .
Committed revision 2.
tux37(57)% svn up
svn: Reference to non-existent revision '2' in filesystem
'/u/t/o/tomab/private/subversion/repos/bugrepos/db'
** It gets better.. The database now shows revision 2, however I can't
check it out. *eyes pop out of head*
tux37(74)% ~/bin/svnlook youngest bugrepos
2
tux37(77)% ~/bin/svnlook info bugrepos/
tomab
2004-04-15 21:08:14 -0500 (Thu, 15 Apr 2004)
4
blah
tux37(79)% ~/bin/svnlook changed bugrepos/
A test2.txt
tux37(80)% svn co
svn+ssh://best-tux.cs.wisc.edu/u/t/o/tomab/private/subversion/repos/bugrepos
bugwc/
A bugwc/test1.txt
Checked out revision 1.
tux37(83)% svn co -r 2
svn+ssh://best-tux.cs.wisc.edu/u/t/o/tomab/private/subversion/repos/bugrepos
bugwc/
svn: Reference to non-existent revision '2' in filesystem
'/u/t/o/tomab/private/subversion/repos/bugrepos/db'
tux37(84)% ~/bin/svnlook history bugrepos
REVISION PATH
-------- ----
2 /
1 /
0 /
** I get frustrated and start over. After toying around for awhile, I
notice that the commits/updates work when I specify a particular machine
instead of letting DNS direct me. I also can get it working from my
windows client that way.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Commits that aren't?
Posted by Tom Brunet <to...@cs.wisc.edu>.
> I'm totally baffled. Does server-side inspection of the repository
> (using 'svnadmin' or 'svnlook', running as the proper user of course)
> reveal anything interesting?
I'm pretty sure that the commit isn't in there (svnadmins and svnlooks
at bottom). And I guarantee I don't have any other folders named
'bugrepos' anywhere. The only other note I should make to head off the
requests beforehand - I do not have write access to mess with these
server binaries (some unknown person manages it). I've attached the ldd
info though on the off chance that that helps anything.
Tom
tux40(131)% ldd svnserve
libsvn_repos-1.so.0 => /unsup/svn-1.0//lib/libsvn_repos-1.so.0
(0x40017000)
libsvn_fs-1.so.0 => /unsup/svn-1.0//lib/libsvn_fs-1.so.0
(0x4002a000)
libsvn_delta-1.so.0 => /unsup/svn-1.0//lib/libsvn_delta-1.so.0
(0x4004a000)
libsvn_subr-1.so.0 => /unsup/svn-1.0//lib/libsvn_subr-1.so.0
(0x40052000)
libsvn_ra_svn-1.so.0 =>
/unsup/svn-1.0//lib/libsvn_ra_svn-1.so.0 (0x40072000)
libaprutil-0.so.0 => /unsup/svn-1.0//lib/libaprutil-0.so.0
(0x40080000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x400aa000)
libdb-4.0.so => /lib/libdb-4.0.so (0x400b1000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40159000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40167000)
libapr-0.so.0 => /unsup/svn-1.0//lib/libapr-0.so.0 (0x40187000)
librt.so.1 => /lib/tls/librt.so.1 (0x401a8000)
libm.so.6 => /lib/tls/libm.so.6 (0x401bb000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x401dd000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4020a000)
libdl.so.2 => /lib/libdl.so.2 (0x4021f000)
libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
tux40(99)% svnadmin verify bugrepos/
* Verified revision 0.
* Verified revision 1.
tux40(107)% svnlook history bugrepos
REVISION PATH
-------- ----
1 /
0 /
tux40(108)% svnlook info bugrepos
tomab
2004-04-15 13:39:11 -0500 (Thu, 15 Apr 2004)
17
This commit works
tux40(117)% svnlook tree bugrepos/
/
test1.txt
tux40(119)% svnlook youngest bugrepos
1
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Commits that aren't?
Posted by kf...@collab.net.
Tom Brunet <to...@cs.wisc.edu> writes:
> C:\users\tomab\bugwc3>svn update
> svn: Reference to non-existent revision '2' in filesystem
> '/u/t/o/tomab/private/subversion/repos/bugrepos/db'
I'm totally baffled. Does server-side inspection of the repository
(using 'svnadmin' or 'svnlook', running as the proper user of course)
reveal anything interesting?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Commits that aren't?
Posted by kf...@collab.net.
"C. Michael Pilato" <cm...@collab.net> writes:
> > This burns people over and over. I sometimes wish we'd just defaulted
> > to HEAD instead of the base revision of ".", but it's a bit late
> > now.
>
> Oops. You didn't read the whole thread -- you'll that not only did he
> run 'svn up', he did any entirely new checkout.
Sorry. I did see Tom's second message, but didn't realize that it
didn't end where I thought it ended (careless paging on my part).
That is truly bizarre behavior.
Tom, does it replicate if instead of checking out to "./", you check
out to a subdir?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Commits that aren't?
Posted by "C. Michael Pilato" <cm...@collab.net>.
kfogel@collab.net writes:
> If you run 'svn update' and then rerun 'svn log', you should be fine.
>
> This burns people over and over. I sometimes wish we'd just defaulted
> to HEAD instead of the base revision of ".", but it's a bit late
> now.
Oops. You didn't read the whole thread -- you'll that not only did he
run 'svn up', he did any entirely new checkout.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Commits that aren't?
Posted by kf...@collab.net.
Tom,
This often happens because someone does
$ svn commit -m "log message"
...
Committed revision 3.
$ svn log
------------------------------------------------------------------------
r2 | jrandom | 2004-04-12 15:31:15 -0500 (Mon, 12 Apr 2004) | 1 line
Reimplement backhoe in ADA.
------------------------------------------------------------------------
r1 | jrandom | 2004-04-12 13:00:00 -0500 (Mon, 12 Apr 2004) | 1 line
Import backhoe.
------------------------------------------------------------------------
$
They see that the logs only go up to r2, and they wonder what happened
to r3. The answer is that their working copy directory "." is still
at r2 (even though some files under it may be at r3), and by default
'svn log' takes its upper revision from ".".
If you run 'svn update' and then rerun 'svn log', you should be fine.
This burns people over and over. I sometimes wish we'd just defaulted
to HEAD instead of the base revision of ".", but it's a bit late now.
-Karl
Tom Brunet <to...@cs.wisc.edu> writes:
> I'm running WinXP and connecting through SSH to a repository on a
> Redhat Linux box. I can check out files from the repository just
> fine. I commit and it goes through the messages saying I added files,
> transmits file data, and I get the message "Committed revision 3.".
>
> The problem is that after this, the actual repository is only at
> revision 2, and that commit never occurred at the server, even though
> my client told me that it did. Now, my working copy thinks it's at
> revision 3, so I can't perform any more commands since the server
> apparently doesn't know about revision 3. The only way to recover my
> local copy is to checkout a fresh copy (which is at revision 2 without
> my changes). Commits done by manually uploading the files to the
> Linux box and doing commits on the server work fine.
>
> Is there any reason why my client would tell me that it committed a
> revision when in fact it didn't? Why does the client update its state
> to a revision that is non-existent? Any suggestions for how to get
> these commits to actually happen?
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Commits that aren't?
Posted by Florian Weimer <fw...@deneb.enyo.de>.
Tom Brunet <to...@cs.wisc.edu> writes:
> The problem is that after this, the actual repository is only at
> revision 2, and that commit never occurred at the server, even though
> my client told me that it did. Now, my working copy thinks it's at
> revision 3, so I can't perform any more commands since the server
> apparently doesn't know about revision 3. The only way to recover my
> local copy is to checkout a fresh copy (which is at revision 2 without
> my changes).
Have you tried running "svn update" in such a situation?
--
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: bigpond.com, postino.it, tiscali.co.uk, tiscali.cz,
tiscali.it, voila.fr.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Commits that aren't?
Posted by Michael W Thelen <th...@cs.utah.edu>.
* Tom Brunet <to...@cs.wisc.edu> [2004-04-15 13:04]:
> >Can you show us a transcript of the bug happening to you? Or give us a
> >hint on how to reproduce the behavior?
>
> Here's a capture of my commands and various things to show I'm not loony
> :) It may very well be something particular to how the university
> firewall works, but I would still expect to see a failure message if the
> end database doesn't update. Anyway...
Thanks for the transcript. For what it's worth as another data point, I ran
through the whole script with svnserve 1.0.1 (r9023, Debian unstable) running
on Linux, and svn command line client 1.0.1 on Windows XP (TortoisePlink 0.53
as the SSH client). Unfortunately, I wasn't able to reproduce the behavior...
the update succeeded as expected, and everything looked fine.
-- Mike
--
Michael W. Thelen
If there were in the world today any large number of people who desired their
own happiness more than they desired the unhappiness of others, we could have
paradise in a few years.
-- Bertrand Russell
Re: Commits that aren't?
Posted by makl <ma...@tigris.org>.
Tom Brunet wrote:
> C:\users\tomab\bugwc>svn commit -m "rev2" test2.txt
> Adding test2.txt
> Transmitting file data .
> Committed revision 2.
> C:\users\tomab\bugwc>svn update
> svn: Reference to non-existent revision '2' in filesystem
> '/u/t/o/tomab/private/subversion/repos/bugrepos/db'
It seems that the URL is wrong.
Could you post the output of 'svn info .', 'svn info test1.txt' and
'svn info test2.txt' before and after the commit?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Commits that aren't?
Posted by Tom Brunet <to...@cs.wisc.edu>.
> We've heard the *opposite* before: where the client says the commit
> failed, when in fact it didn't. But this is completely new.
>
> Can you show us a transcript of the bug happening to you? Or give us a
> hint on how to reproduce the behavior?
Here's a capture of my commands and various things to show I'm not loony
:) It may very well be something particular to how the university
firewall works, but I would still expect to see a failure message if the
end database doesn't update. Anyway...
Here's the server end where everything works fine:
********
tux40(64)% mkdir bugrepos
tux40(65)% svnadmin create bugrepos/
tux40(66)% mkdir bugwc
tux40(67)% cd bugwc
tux40(68)% svn co file:///u/t/o/tomab/private/subversion/repos/bugrepos ./
Checked out revision 0.
tux40(69)% ls -al
total 6
drwxr-x--- 3 tomab tomab 2048 Apr 15 13:38 ./
drwxrwxrwx 8 tomab tomab 2048 Apr 15 13:38 ../
drwxr-x--- 7 tomab tomab 2048 Apr 15 13:38 .svn/
tux40(70)% echo File to be committed 1 > test1.txt
tux40(71)% svn add test1.txt
A test1.txt
tux40(72)% svn commit -m "This commit works" test1.txt
Adding test1.txt
Transmitting file data .
Committed revision 1.
tux40(73)% cd ..
tux40(74)% rm -rf bugwc/
tux40(75)% mkdir bugwc
tux40(76)% cd bugwc
tux40(77)% svn co file:///u/t/o/tomab/private/subversion/repos/bugrepos ./
A test1.txt
Checked out revision 1.
tux40(78)% ls
test1.txt
********
Here's what it looks like from the win2k client (Same happens at home on
winxp)
********
C:\users\tomab>mkdir bugwc
C:\users\tomab>cd bugwc
C:\users\tomab\bugwc>svn co
svn+ssh://best-tux.cs.wisc.edu/u/t/o/tomab/private/s
ubversion/repos/bugrepos ./
A test1.txt
Checked out revision 1.
C:\users\tomab\bugwc>dir
Volume in drive C has no label.
Volume Serial Number is 1CF3-1028
Directory of C:\users\tomab\bugwc
04/15/2004 01:42p <DIR> .
04/15/2004 01:42p <DIR> ..
04/15/2004 01:42p 23 test1.txt
1 File(s) 23 bytes
2 Dir(s) 23,142,804,480 bytes free
C:\users\tomab\bugwc>echo This commit actually fails >test2.txt
C:\users\tomab\bugwc>dir
Volume in drive C has no label.
Volume Serial Number is 1CF3-1028
Directory of C:\users\tomab\bugwc
04/15/2004 01:42p <DIR> .
04/15/2004 01:42p <DIR> ..
04/15/2004 01:42p 23 test1.txt
04/15/2004 01:42p 29 test2.txt
2 File(s) 52 bytes
2 Dir(s) 23,142,804,480 bytes free
C:\users\tomab\bugwc>svn add test2.txt
A test2.txt
C:\users\tomab\bugwc>svn commit -m "rev2" test2.txt
Adding test2.txt
Transmitting file data .
Committed revision 2.
C:\users\tomab\bugwc>svn update
svn: Reference to non-existent revision '2' in filesystem
'/u/t/o/tomab/private/
subversion/repos/bugrepos/db'
C:\users\tomab\bugwc>cd ..
C:\users\tomab>del /s bugwc
<snip>
C:\users\tomab>mkdir bugwc
C:\users\tomab>cd bugwc
C:\users\tomab\bugwc>svn co
svn+ssh://best-tux.cs.wisc.edu/u/t/o/tomab/private/s
ubversion/repos/bugrepos ./
A test1.txt
Checked out revision 1.
********
Hope that helps any...
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Commits that aren't?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2004-04-15 at 13:13, Tom Brunet wrote:
> The problem is that after this, the actual repository is only at
> revision 2, and that commit never occurred at the server, even though my
> client told me that it did.
This shouldn't be possible! I've never heard of or seen anyone report
anything like this, ever.
We've heard the *opposite* before: where the client says the commit
failed, when in fact it didn't. But this is completely new.
Can you show us a transcript of the bug happening to you? Or give us a
hint on how to reproduce the behavior?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Commits that aren't?
Posted by Rob Segal <rs...@3dna.net>.
I had a similar problem which I posted on the Tortoise SVN mailing list.
My problem seemed to be with deleting large numbers of files from a
repository using Tortoise SVN. One of the developers I work with was trying
to delete
a folder which contain 3000+ files. The deletion seemed to work, the
deletion action was committed so all the files we're seemingly removed. Yet
when the repository is viewed through IE or svnadmin the files are still
there. The revision number has been incremented but the files remain.
Also, when another commit was attempted from this same developers machine
the files that should have been deleted we're visible again in the list of
files to commit. When I deleted this folder using SVN command line the
deletion worked fine. I solved my problem by using the command line that's
why I figured it was a Tortoise SVN issue.
Hope that helps in some way.
Server is on Windows XP version 0.35.1 with Apache 2.0.48
All developers are using Tortoise SVN 0.24 build 554 UNICODE
-----Original Message-----
From: Tom Brunet [mailto:tomab@cs.wisc.edu]
Sent: April 15, 2004 2:13 PM
To: users@subversion.tigris.org
Subject: Commits that aren't?
I'm running WinXP and connecting through SSH to a repository on a Redhat
Linux box. I can check out files from the repository just fine. I
commit and it goes through the messages saying I added files, transmits
file data, and I get the message "Committed revision 3.".
The problem is that after this, the actual repository is only at
revision 2, and that commit never occurred at the server, even though my
client told me that it did. Now, my working copy thinks it's at
revision 3, so I can't perform any more commands since the server
apparently doesn't know about revision 3. The only way to recover my
local copy is to checkout a fresh copy (which is at revision 2 without
my changes). Commits done by manually uploading the files to the Linux
box and doing commits on the server work fine.
Is there any reason why my client would tell me that it committed a
revision when in fact it didn't? Why does the client update its state
to a revision that is non-existent? Any suggestions for how to get
these commits to actually happen?
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org