Albert has it right. Just do a full get and the problem will go away. If a developer has changed a file, SJ will notice that the file is not read-only and will prompt you accordingly, so I think a full get is a pretty safe bet. Back up your dev directory before doing the get if you want to be safe.
----- Original Message ----
From: Albert Moliner <[EMAIL PROTECTED]>
To: sourcejammer-users@lists.sourceforge.net; [EMAIL PROTECTED]
Sent: Tuesday, November 7, 2006 3:55:45 AM
Subject: Re: [SourceJammer-users] Files out of sync but identical
Hello, Jonathan.
What provokes that disgusting effect is that the
new server's URL is different from the old one's. Unfortunately, the only
solution I know for it requires that all client computers resolve the old
server's name as the new server's IP. 8-S Then, the server connection details
should be restored to the old ones, so that clients think they are still
connecting to the old one, though the repositories are in the new
server.
If oldserver does
not exist anymore, you may rename the new one as oldserver, and restore all the URLs to their previous
value, and then everything should work fine again (except for the files that
have been managed with the new URL, but these are negligible compared to the
amount of those which have not).
Renaming the servers is also a simple shortcut when
possible. However, if that cannot be done because they are used in multiple
other contexts, then you'll have to force the client computers to believe they
are working with the old one when they in fact use the newer one. To achieve it,
you must define the IP in the hosts file (/etc/hosts for Unix, C:\WINNT\system32\drivers\etc\hosts for Windows). It's
a plain text file where you must add a line like the following:
10.0.0.15 oldserver
From now on, everytime you use a URL with oldserver, you'll be accessing newserver, whose IP is
10.0.0.15. So,
clients using the old URL will think it's the same repository and will check the
files update correctly.
The one drawback of this is that, in those
computers, you won't be able to use oldserver
as the name for the server at 10.0.0.7. The computers where the hosts file
has not been modified can indeed still use the old name, and often they are
a set different from the SJ clients and there's no problem with that. But if the
SJ clients need the old server for other purpuses as well, then there's a
conflict, and all this stuff will not suit you at all. I have no nice fix for
it, sorry.
Well, I hope this is useful some way or another to
you,
Albert.
----- Original Message -----
Sent: Monday, November 06, 2006 6:10
PM
Subject: [SourceJammer-users] Files out
of sync but identical
Hi,
We've just moved our archive to a new server.
Everything is good except that local files that used to be in sync with the
old server are now out of sync with the new server. The files actually are
identical; when we do a diff, there are no differences. If we do a get, the
files are then in sync, but we don't want to do a mass get for fear of
actually overwriting a program that has changed (for example, a programmer
edited a program without checking it out first).
What can we do to correctly reset the sync
indicator?
Thanks,
Jonathan Rix
-------------------------------------------------------------------------
Using
Tomcat but need to do more? Need to support web services, security?
Get
stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
SourceJammer-users
mailing
list
SourceJammer-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sourcejammer-users
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642