You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Dave Tingling <da...@infotechfl.com> on 2011/05/11 17:50:58 UTC
Random files being "reverted" on one repository
Hi List,
We administer subversion (v 1.4.2, r22196 on CentOS 5.5) for a
development company, and have over 150 active repositories, but we are
not subversion experts. We are experiencing an issue with just one
particular repository.
When programmers run an update against this one repository (using either
TortoiseSVN 1.6.15 or Slik Subversion 1.6.16 on Windows 7 Pro SP1), they
observe that they sometimes get---to coin their term---"frankenstein"
versions of arbitrary files. As an example scenario:
1) - Developer A: adds, edits and commits a file X,
2) - Developer A: later, again edits and commits file X,
3) - Developer A: still later, again edits and commits file X,
4) - Developer N: who has never before seen file X, runs an update. She
gets a weird version of file X which contains only *some* lines of the
set of changes made by Developer A in each of the edit/commit sessions
(1), (2), and (3).
We cannot replicate the problem on demand, but it recurs with
(seemingly) random files at random times. The worst thing is that when
an update silently "reverts" some unknown file (to a "frankenstein"
version), it is subsequently committed as a new version by the
unsuspecting developer.
We've tried exporting and re-importing the code to a new repository, but
the issue has persisted. "Svnadmin verify" finds no errors in any
revisions. Our latest move was to disable the Windows Search service,
but if that's really the problem, our other developers should be seeing
this with other repositories. Any advice on how to
duplicate/troubleshoot the cause of this problem will be greatly
appreciated.
Thank you,
Dave
Re: Random files being "reverted" on one repository
Posted by Dave Tingling <da...@infotechfl.com>.
Thorsten Schöning wrote:
> Guten Tag Dave Tingling,
> am Mittwoch, 11. Mai 2011 um 17:50 schrieben Sie:
>
>
>> 1) - Developer A: adds, edits and commits a file X,
>> 2) - Developer A: later, again edits and commits file X,
>> 3) - Developer A: still later, again edits and commits file X,
>> 4) - Developer N: who has never before seen file X, runs an update. She
>> gets a weird version of file X which contains only *some* lines of the
>> set of changes made by Developer A in each of the edit/commit sessions
>> (1), (2), and (3).
>>
> And this behaviour is reproducible, meaning that every time the file x
> is deleted from the local working copy of dev N on each and every
> update the newly created file is freaky? Is it freaky on clean
> checkouts, too?
>
>
>> We cannot replicate the problem on demand, but it recurs with
>> (seemingly) random files at random times. The worst thing is that when
>> an update silently "reverts" some unknown file (to a "frankenstein"
>> version), it is subsequently committed as a new version by the
>> unsuspecting developer.
>>
> How do you know that the update is the problem? If the file in the
> repository looks fine, I don't think the problem comes with the
> update, but afterwards, on any build actions or stuff like that. As
> you say: The freaky file is committed by dev N and that is the
> problem, between update and commit it is somehow changed. The update
> process just make changes to the local file, if already present, that
> are on the server and it's pretty likely that this will work as
> expected.
>
> The interesting part is between update and commit of dev N and in your
> case i would look at the diffs to maybe get an idea of the tool or
> process or whatever is responsible for the changes in the file. Maybe
> there's something common in every changes?
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
>
Thanks for the quick reply and your guidance Thorsten. I'm not 100%
sure. I'll work with the developers to clarify, and then will report back.
Thank you,
-Dave
Re: Random files being "reverted" on one repository
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Dave Tingling,
am Donnerstag, 12. Mai 2011 um 16:26 schrieben Sie:
> We will. Let me make sure I understand you: you're suggesting testing
> multiple commits, but each consecutive commit will be an "undoing" of
> the previous change. If that's true, after many many commits, I have
> only ever really committed two different variations of the file, in
> alternation. Is that what you intend?
Yes.
> Assuming I understood you correctly above, would there be any value if I
> commit a completely new change to the same file each time, perhaps (for
> agument's sake) adding a new, predictable, unique line to the file? I
> would add the numeral '1' as line one, then next time add the numeral
> '2' as line 2, etc etc. always appending. What do you think?
Using this approach you get to many differences over time and maybe
it's too hard to see any correlations to the changes made which result
in the freaky file. You only add one line in your commit but the
result is that you never repeat the exactly two updates you have with
my suggestion. You always have a new file with completely different
content and not only to versions of the file. But I'm really only
guessing, your problem really sounds strange.
> Understood. Just to clarify our situation, there no single one
> problematic developer (nor file, for that matter). This could happen to
> anyone of the team---when some random person updates, a file is "wrong".
> It could be any one developer, any file.
You have to start somewhere. In problems like yours I would suggest
running Filemon during the update but the logs surely will get huge
and if you manage to get the error itself reproducible somehow running
Filemon next time will be of more benefit.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tschoening@am-soft.de
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: Random files being "reverted" on one repository
Posted by Dave Tingling <da...@infotechfl.com>.
Thorsten Schöning wrote:
> I would try to test a bit: Take a dev where the file never was freaky
> and let him produce small changes which are committable, e.g. add a
> newline at the end of the file and remove it or stuff like that. But
> it should be always the same changes.
We will. Let me make sure I understand you: you're suggesting testing
multiple commits, but each consecutive commit will be an "undoing" of
the previous change. If that's true, after many many commits, I have
only ever really committed two different variations of the file, in
alternation. Is that what you intend?
Assuming I understood you correctly above, would there be any value if I
commit a completely new change to the same file each time, perhaps (for
agument's sake) adding a new, predictable, unique line to the file? I
would add the numeral '1' as line one, then next time add the numeral
'2' as line 2, etc etc. always appending. What do you think?
> After each change let your
> problematic developer N update the file and see if the error happens
> and if it always results in the same wrong changes.
>
Understood. Just to clarify our situation, there no single one
problematic developer (nor file, for that matter). This could happen to
anyone of the team---when some random person updates, a file is "wrong".
It could be any one developer, any file.
> I can't believe the error is in the subversion code, sounds more like
> a client problem to me. Client side scripts, programs locking the file
> and all that kind of stuff.
>
We are inclined to agree. Will proceed to test. Thanks very much.
-Dave
Re: Random files being "reverted" on one repository
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Dave Tingling,
am Mittwoch, 11. Mai 2011 um 21:40 schrieben Sie:
>> When someone experiences the error, Their local copy will show as
>> modified immediately after the update, and attempting to commit the
>> working copy directory will include these changes. No conflict will be
>> detected.
I would try to test a bit: Take a dev where the file never was freaky
and let him produce small changes which are committable, e.g. add a
newline at the end of the file and remove it or stuff like that. But
it should be always the same changes. After each change let your
problematic developer N update the file and see if the error happens
and if it always results in the same wrong changes.
I can't believe the error is in the subversion code, sounds more like
a client problem to me. Client side scripts, programs locking the file
and all that kind of stuff.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tschoening@am-soft.de
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: Random files being "reverted" on one repository
Posted by Dave Tingling <da...@infotechfl.com>.
Thorsten Schöning wrote:
> Guten Tag Dave Tingling,
> am Mittwoch, 11. Mai 2011 um 17:50 schrieben Sie:
> And this behaviour is reproducible, meaning that every time the file x
> is deleted from the local working copy of dev N on each and every
> update the newly created file is freaky? Is it freaky on clean
> checkouts, too?
>
Thorsten,
It is not reproducible as you propose above: deleting the local file
and updating again has (so far) resulted in a good copy. I received
these further comments from one of the developers:
> <begin quote>
> In this case, there are no build actions to speak of. These are pretty
> much just perl files, and we don't use visual studio or any project
> management type apps. A handful of us use Komodo for project
> management, but the problem seems to impact people regardless of
> editor or SVN client. The problem does in fact happen during the
> update phase, because other people can do the same update and get the
> correct version of the file.
>
> When someone experiences the error, Their local copy will show as
> modified immediately after the update, and attempting to commit the
> working copy directory will include these changes. No conflict will be
> detected.
> <end quote>
To clarify, I confirmed that they do not use Komodo to talk directly to
the server; they only point it to working-copies.
Thanks,
-Dave
Re: Random files being "reverted" on one repository
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Dave Tingling,
am Mittwoch, 11. Mai 2011 um 17:50 schrieben Sie:
> 1) - Developer A: adds, edits and commits a file X,
> 2) - Developer A: later, again edits and commits file X,
> 3) - Developer A: still later, again edits and commits file X,
> 4) - Developer N: who has never before seen file X, runs an update. She
> gets a weird version of file X which contains only *some* lines of the
> set of changes made by Developer A in each of the edit/commit sessions
> (1), (2), and (3).
And this behaviour is reproducible, meaning that every time the file x
is deleted from the local working copy of dev N on each and every
update the newly created file is freaky? Is it freaky on clean
checkouts, too?
> We cannot replicate the problem on demand, but it recurs with
> (seemingly) random files at random times. The worst thing is that when
> an update silently "reverts" some unknown file (to a "frankenstein"
> version), it is subsequently committed as a new version by the
> unsuspecting developer.
How do you know that the update is the problem? If the file in the
repository looks fine, I don't think the problem comes with the
update, but afterwards, on any build actions or stuff like that. As
you say: The freaky file is committed by dev N and that is the
problem, between update and commit it is somehow changed. The update
process just make changes to the local file, if already present, that
are on the server and it's pretty likely that this will work as
expected.
The interesting part is between update and commit of dev N and in your
case i would look at the diffs to maybe get an idea of the tool or
process or whatever is responsible for the changes in the file. Maybe
there's something common in every changes?
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tschoening@am-soft.de
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: Random files being "reverted" on one repository
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Dave Tingling,
am Mittwoch, 11. Mai 2011 um 22:03 schrieben Sie:
> Is it
> possible that we're seeing this problem because of using 1.6 clients
> against this server?
I don't think so, we use Subversion 1.4.x as server and bleeding edge
TortoiseSVN with Subversion 1.6.x libs without any problems for month.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tschoening@am-soft.de
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: Random files being "reverted" on one repository
Posted by Daniel Shahaf <da...@elego.de>.
Dave Tingling wrote on Wed, May 11, 2011 at 16:03:20 -0400:
> Daniel Shahaf wrote:
> >Which tells me your repository was created by Subversion 1.4. Nothing
> >unexpected...
> I've learned that clients update their working-copy layout to
> whatever that client is built for. Considering http://stackoverflow.com/questions/1364618/how-do-i-determine-svn-working-copy-layout-version,
> I realize that our 1.6.x clients indeed have '10' on the first line
> of .svn/entries.
>
Correct, but that's a client-side issue, which is a few miles (and
layers of abstraction) away from where we were two levels of >-quoting
ago...
> What do these $REPOS/format = 5 and $REPOS/db/format = 2 each
> mean, please?
These are the repository format number and the filesystem backend format
number. When svnadmin 1.4 sees a format number greater than 2 on a FSFS
repository, it will abort with an error to the effect of "This
repository is newer than I know how to handle". (It doesn't know how
to modify a format-3 FSFS without corrupting it.) Ditto for the other
format files.
Specific details currently live at the documentation comments of the following macros:
subversion/libsvn_repos/repos.h:SVN_REPOS__FORMAT_NUMBER
subversion/libsvn_fs_fs/fs.h:SVN_FS_FS__FORMAT_NUMBER
subversion/libsvn_fs_base/fs.h:SVN_FS_BASE__FORMAT_NUMBER
(In a nutshell: the filesystem is everything under the db/ directory ---
the versioned tree and revprops; the repository is everything under
db/'s parent directory; the filesystem format number is private to the
concrete FS provider (fsfs or bdb), rather than to the FS library
itself)
> (I'll be happy to document in the FAQ if I can :-)
Thanks for the readiness :-)
The FAQ source lives at http://svn.apache.org/repos/asf/subversion/site/publish/faq.html,
and patch submission guideliens are at http://subversion.apache.org/patches.
> Is it possible that we're seeing this problem because of using 1.6
> clients against this server?
>
It's possible that we have some bugs in the compatibility code for
1.6.16 clients and 1.4.x servers.
> Thanks,
> -Dave
Re: Random files being "reverted" on one repository
Posted by Dave Tingling <da...@infotechfl.com>.
Daniel Shahaf wrote:
> Which tells me your repository was created by Subversion 1.4. Nothing
> unexpected...
>
I've learned that clients update their working-copy layout to whatever
that client is built for. Considering
http://stackoverflow.com/questions/1364618/how-do-i-determine-svn-working-copy-layout-version,
I realize that our 1.6.x clients indeed have '10' on the first line of
.svn/entries.
What do these $REPOS/format = 5 and $REPOS/db/format = 2 each mean,
please? (I'll be happy to document in the FAQ if I can :-) Is it
possible that we're seeing this problem because of using 1.6 clients
against this server?
Thanks,
-Dave
Re: Random files being "reverted" on one repository
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Which tells me your repository was created by Subversion 1.4. Nothing
unexpected...
Dave Tingling wrote on Wed, May 11, 2011 at 14:44:52 -0400:
> Thanks Daniel. Results from in the repo dir on the server::
>
> [dt@s..]$ cat format
> 5
> [dt@s..]$ cat db/fs-type
> fsfs
> [dt@s..]$ cat db/format
> 2
>
> Daniel Shahaf wrote:
> >Dave Tingling wrote on Wed, May 11, 2011 at 12:38:08 -0400:
> >>I'm not sure how to check what repo format is on the server, though.
> >cat $REPOS/format
> >cat $REPOS/db/fs-type
> >cat $REPOS/db/format
> >
> >
> >(it'd be nice to document this in the FAQ along with the
> >format number -> minor version number mappings)
>
>
> --
> Dave Tingling
> Business Process Analyst
> Info Tech, Inc.
> 352-381-4512 (direct)
> 352-381-4444 (fax)
>
Re: Random files being "reverted" on one repository
Posted by Dave Tingling <da...@infotechfl.com>.
Thanks Daniel. Results from in the repo dir on the server::
[dt@s..]$ cat format
5
[dt@s..]$ cat db/fs-type
fsfs
[dt@s..]$ cat db/format
2
Daniel Shahaf wrote:
> Dave Tingling wrote on Wed, May 11, 2011 at 12:38:08 -0400:
>
>> I'm not sure how to check what repo format is on the server, though.
>>
> cat $REPOS/format
> cat $REPOS/db/fs-type
> cat $REPOS/db/format
>
>
> (it'd be nice to document this in the FAQ along with the
> format number -> minor version number mappings)
>
--
Dave Tingling
Business Process Analyst
Info Tech, Inc.
352-381-4512 (direct)
352-381-4444 (fax)
Re: Random files being "reverted" on one repository
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Dave Tingling wrote on Wed, May 11, 2011 at 12:38:08 -0400:
> I'm not sure how to check what repo format is on the server, though.
cat $REPOS/format
cat $REPOS/db/fs-type
cat $REPOS/db/format
(it'd be nice to document this in the FAQ along with the
format number -> minor version number mappings)
Re: Random files being "reverted" on one repository
Posted by Dave Tingling <da...@infotechfl.com>.
Daniel Shahaf wrote:
> fsfs or bdb?
>
> Tried 1.5.7 / 1.6.16 server?
>
> Dave Tingling wrote on Wed, May 11, 2011 at 11:50:58 -0400:
>
>> Hi List,
>>
>> We administer subversion (v 1.4.2, r22196 on CentOS 5.5) for a
>> development company, and have over 150 active repositories, but we
>> are not subversion experts. We are experiencing an issue with just
>> one particular repository.
>>
>> When programmers run an update against this one repository (using
>> either TortoiseSVN 1.6.15 or Slik Subversion 1.6.16 on Windows 7 Pro
>> SP1), they observe that they sometimes get---to coin their
>> term---"frankenstein" versions of arbitrary files. As an example
>> scenario:
>>
>> 1) - Developer A: adds, edits and commits a file X,
>> 2) - Developer A: later, again edits and commits file X,
>> 3) - Developer A: still later, again edits and commits file X,
>> 4) - Developer N: who has never before seen file X, runs an update.
>> She gets a weird version of file X which contains only *some* lines
>> of the set of changes made by Developer A in each of the edit/commit
>> sessions (1), (2), and (3).
>>
>> We cannot replicate the problem on demand, but it recurs with
>> (seemingly) random files at random times. The worst thing is that
>> when an update silently "reverts" some unknown file (to a
>> "frankenstein" version), it is subsequently committed as a new
>> version by the unsuspecting developer.
>>
>> We've tried exporting and re-importing the code to a new repository,
>> but the issue has persisted. "Svnadmin verify" finds no errors in
>> any revisions. Our latest move was to disable the Windows Search
>> service, but if that's really the problem, our other developers
>> should be seeing this with other repositories. Any advice on how to
>> duplicate/troubleshoot the cause of this problem will be greatly
>> appreciated.
>>
>> Thank you,
>> Dave
>>
FSFS. My understanding is that the 1.4.2 (reported by running "svn
--version" on the server) is what ships with CentOS 5.5, and that it is
"backported" so that it includes recent updates, bugfixes, etc. I'm not
sure how to check what repo format is on the server, though. We have not
yet tried 1.5.7 or 1.6.16 server.
Thanks,
-Dave
Re: Random files being "reverted" on one repository
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
fsfs or bdb?
Tried 1.5.7 / 1.6.16 server?
Dave Tingling wrote on Wed, May 11, 2011 at 11:50:58 -0400:
> Hi List,
>
> We administer subversion (v 1.4.2, r22196 on CentOS 5.5) for a
> development company, and have over 150 active repositories, but we
> are not subversion experts. We are experiencing an issue with just
> one particular repository.
>
> When programmers run an update against this one repository (using
> either TortoiseSVN 1.6.15 or Slik Subversion 1.6.16 on Windows 7 Pro
> SP1), they observe that they sometimes get---to coin their
> term---"frankenstein" versions of arbitrary files. As an example
> scenario:
>
> 1) - Developer A: adds, edits and commits a file X,
> 2) - Developer A: later, again edits and commits file X,
> 3) - Developer A: still later, again edits and commits file X,
> 4) - Developer N: who has never before seen file X, runs an update.
> She gets a weird version of file X which contains only *some* lines
> of the set of changes made by Developer A in each of the edit/commit
> sessions (1), (2), and (3).
>
> We cannot replicate the problem on demand, but it recurs with
> (seemingly) random files at random times. The worst thing is that
> when an update silently "reverts" some unknown file (to a
> "frankenstein" version), it is subsequently committed as a new
> version by the unsuspecting developer.
>
> We've tried exporting and re-importing the code to a new repository,
> but the issue has persisted. "Svnadmin verify" finds no errors in
> any revisions. Our latest move was to disable the Windows Search
> service, but if that's really the problem, our other developers
> should be seeing this with other repositories. Any advice on how to
> duplicate/troubleshoot the cause of this problem will be greatly
> appreciated.
>
> Thank you,
> Dave
Re: Random files being "reverted" on one repository
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/5/12 Dave Tingling <da...@infotechfl.com>:
> Thanks for those tips Konstantin.
>
> There are about 16 developers. Is there anything I can look at on the server
> side to determine whether such bad directory copy/moves have been done, and
> perhaps by whom?
>
When developer B notices "Frankenstein" file appearing in his working
copy he should
1. Look at the history of this file to find who committed it. That is
"svn log --limit 3" command. (Or with limit of 1, only recent entries
do matter). (Or using TortoiseSVN > Log command in its menu).
2. From the history find who and when committed the file. Let's say it
was developer A.
3. Go to A and ask what changes were committed and call "svn info" on
that file in A's working copy. (Or using Windows Explorer > File
Properties > look at "Subversion" tab, as I wrote before). Pay
attention to the file's path in repository.
In TortoiseSVN there is "Change for modifications" dialog that I
think should show if anything is wrong with files hierarchy in the
working copy.
>> On the server: what protocol you are using to access the repository and
>> commit the files?
>
> HTTPS...I'm not sure what mechanisms happen "within" or "lower than" that.
> Is this a helpful answer? If you need more info, please let me know how I
> can find it out. I personally am a facilitator for researching this issue,
> I'm not an admin.
This is good. HTTPS passes proxies safely and unchanged.
One more suggestion: you might consider about installing a post-commit
hook at the repository. Tasks that can be performed by such a hook:
a) make a dump of the recent commit, b) send a copy of commit diff to
an e-mail address. etc.
Best regards,
Konstantin Kolinko
RE: Random files being "reverted" on one repository
Posted by Bob Archer <Bo...@amsi.com>.
> Hi Bob,
> > Does the same team us more than one repository? Or is each repo
> used by different people and teams?
> >
> >
> Some members of this team do work with other repositories. But this
> small team (7-10 active devs) is the only one that touches this
> problematic repository.
This makes me think it isn't the repository but the users and the tools/procedures they are using.
> > Is the update funky when there is no file on the disk, or only
> when merging into an existing file?
> >
> >
> Both are true...if the file never existed locally before, it
> arrives
> funky. And if it did exist before, it ends up funky.
Ok, this leaves out the encoding possibility... because I think that would only show issues during an update in which it is merging changes with the current file on disk.
> > What encoding are the files using? I have found that svn doesn't
> really work well with Unicode files.
> >
> I had thought that different encoding on different
> workstations/files
> might be an issue, but don't know of a good way to investigate (I
> found
> a Unix tool, but nothing concrete for Win7). Did you mean the files
> on
> the various workstations, or are you thinking of some setting on
> the
> server-side? Please suggest how to best check the encoding(s?) to
> answer
> your question.
>
Most good editors allow you to view the current encoding on a file. I use Notepad++ and it is able to tell you the encoding of a file you open. You also might want to see if svn:mime-type is set on any of the files that have problems.
> I should mention that at least one member of this team is using a
> 32-bit
> PC/OS and 32-bit current version of Tortoise, the others are using
> 64-bit versions of the OS/Tortoise combo.
> > Is it always the same file(s) or different ones each time?
> >
> Different files each time the incident is observed. This incident
> is not
> observed after every update---only occasionally.
Yes, that's the worst kind of problem to fix. Although, I'm sure you will figure it out when you find that it isn't "random" and actually happens after "something specific" each time. But, until you narrow that down I doubt you'll be able to "fix" it.
BOb
Re: Random files being "reverted" on one repository
Posted by Dave Tingling <da...@infotechfl.com>.
Hi Bob,
> Does the same team us more than one repository? Or is each repo used by different people and teams?
>
>
Some members of this team do work with other repositories. But this
small team (7-10 active devs) is the only one that touches this
problematic repository.
> Is the update funky when there is no file on the disk, or only when merging into an existing file?
>
>
Both are true...if the file never existed locally before, it arrives
funky. And if it did exist before, it ends up funky.
> What encoding are the files using? I have found that svn doesn't really work well with Unicode files.
>
I had thought that different encoding on different workstations/files
might be an issue, but don't know of a good way to investigate (I found
a Unix tool, but nothing concrete for Win7). Did you mean the files on
the various workstations, or are you thinking of some setting on the
server-side? Please suggest how to best check the encoding(s?) to answer
your question.
I should mention that at least one member of this team is using a 32-bit
PC/OS and 32-bit current version of Tortoise, the others are using
64-bit versions of the OS/Tortoise combo.
> Is it always the same file(s) or different ones each time?
>
Different files each time the incident is observed. This incident is not
observed after every update---only occasionally.
Thanks,
-Dave
RE: Random files being "reverted" on one repository
Posted by Bob Archer <Bo...@amsi.com>.
> Thanks for those tips Konstantin.
>
> There are about 16 developers. Is there anything I can look at on
> the
> server side to determine whether such bad directory copy/moves have
> been
> done, and perhaps by whom?
>
> > On the server: what protocol you are using to access the
> repository and
> > commit the files?
> HTTPS...I'm not sure what mechanisms happen "within" or "lower
> than"
> that. Is this a helpful answer? If you need more info, please let
> me
> know how I can find it out. I personally am a facilitator for
> researching this issue, I'm not an admin.
>
> > I hope there is no proxy in between you and client,
> > that performs some sort of url rewriting?
> >
> No proxy, no rewriting.
> >
> >> We administer subversion (v 1.4.2, r22196 on CentOS 5.5)
> >>
> > Anyway, 1.4.2 is very old, and misses a number of fixes in 1.4.x
> line,
> > not to mention the later versions. In some other thread recently
> when
> > "CentOS 5.5" was mentioned one of the answers was to upgrade to
> 5.6
> > ASAP.
> >
> Upgrading is non-trivial for us, for internal policy reasons
> (recall
> 150+ active repos). We realize that "upgrade now" would be a very
> strong
> encouragement in this forum, and understand that rationale. With
> due
> respect to that idea, I'm hoping we can identify why only one
> repository
> manifests this issue, and maybe why, after an export / import to a
> new
> repository, the problem appears in the new repo.
Does the same team us more than one repository? Or is each repo used by different people and teams?
Is the update funky when there is no file on the disk, or only when merging into an existing file?
What encoding are the files using? I have found that svn doesn't really work well with Unicode files.
Is it always the same file(s) or different ones each time?
BOb
Re: Random files being "reverted" on one repository
Posted by Dave Tingling <da...@infotechfl.com>.
Thanks for those tips Konstantin.
There are about 16 developers. Is there anything I can look at on the
server side to determine whether such bad directory copy/moves have been
done, and perhaps by whom?
> On the server: what protocol you are using to access the repository and
> commit the files?
HTTPS...I'm not sure what mechanisms happen "within" or "lower than"
that. Is this a helpful answer? If you need more info, please let me
know how I can find it out. I personally am a facilitator for
researching this issue, I'm not an admin.
> I hope there is no proxy in between you and client,
> that performs some sort of url rewriting?
>
No proxy, no rewriting.
>
>> We administer subversion (v 1.4.2, r22196 on CentOS 5.5)
>>
> Anyway, 1.4.2 is very old, and misses a number of fixes in 1.4.x line,
> not to mention the later versions. In some other thread recently when
> "CentOS 5.5" was mentioned one of the answers was to upgrade to 5.6
> ASAP.
>
Upgrading is non-trivial for us, for internal policy reasons (recall
150+ active repos). We realize that "upgrade now" would be a very strong
encouragement in this forum, and understand that rationale. With due
respect to that idea, I'm hoping we can identify why only one repository
manifests this issue, and maybe why, after an export / import to a new
repository, the problem appears in the new repo.
Again, thank you very much.
-Dave
Re: Random files being "reverted" on one repository
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/5/11 Dave Tingling <da...@infotechfl.com>:
> Hi List,
>
> We administer subversion (v 1.4.2, r22196 on CentOS 5.5) for a development
> company, and have over 150 active repositories, but we are not subversion
> experts. We are experiencing an issue with just one particular repository.
>
> When programmers run an update against this one repository (using either
> TortoiseSVN 1.6.15 or Slik Subversion 1.6.16 on Windows 7 Pro SP1), they
> observe that they sometimes get---to coin their term---"frankenstein"
> versions of arbitrary files. As an example scenario:
>
> 1) - Developer A: adds, edits and commits a file X,
> 2) - Developer A: later, again edits and commits file X,
> 3) - Developer A: still later, again edits and commits file X,
> 4) - Developer N: who has never before seen file X, runs an update. She gets
> a weird version of file X which contains only *some* lines of the set of
> changes made by Developer A in each of the edit/commit sessions (1), (2),
> and (3).
>
On client: it is easy to break one's working copy if you move
directories around mindlessly.
One should always use svn command when moving around directories, and
never the system commands.
http://tortoisesvn.net/mostforgottenfeature.html
On *nix that is the difference between "mv" and "svn mv". If you mv a
directory the ".svn" subdirectory of it is moved along, but still
points to the old location. Trying to commit any file in the moved
directory will actually commit it to the original location, because of
that stale ".svn" subdirectory.
The "svn info" command (or Subversion tab in file properties dialog in
Windows Explorer on a PC where TortoiseSVN is installed) what is
repository path for any particular file in the working copy.
On the server: what protocol you are using to access the repository and
commit the files? I hope there is no proxy in between you and client,
that performs some sort of url rewriting?
> We administer subversion (v 1.4.2, r22196 on CentOS 5.5)
Anyway, 1.4.2 is very old, and misses a number of fixes in 1.4.x line,
not to mention the later versions. In some other thread recently when
"CentOS 5.5" was mentioned one of the answers was to upgrade to 5.6
ASAP.
Best regards,
Konstantin Kolinko
Re: Random files being "reverted" on one repository
Posted by Dave Tingling <da...@infotechfl.com>.
Campbell Allan wrote:
> On Wednesday 11 May 2011, Dave Tingling wrote:
>
>> Hi List,
>>
>> We administer subversion (v 1.4.2, r22196 on CentOS 5.5) for a
>> development company, and have over 150 active repositories, but we are
>> not subversion experts. We are experiencing an issue with just one
>> particular repository.
>>
>> When programmers run an update against this one repository (using either
>> TortoiseSVN 1.6.15 or Slik Subversion 1.6.16 on Windows 7 Pro SP1), they
>> observe that they sometimes get---to coin their term---"frankenstein"
>> versions of arbitrary files. As an example scenario:
>>
>> 1) - Developer A: adds, edits and commits a file X,
>> 2) - Developer A: later, again edits and commits file X,
>> 3) - Developer A: still later, again edits and commits file X,
>> 4) - Developer N: who has never before seen file X, runs an update. She
>> gets a weird version of file X which contains only *some* lines of the
>> set of changes made by Developer A in each of the edit/commit sessions
>> (1), (2), and (3).
>>
>> We cannot replicate the problem on demand, but it recurs with
>> (seemingly) random files at random times. The worst thing is that when
>> an update silently "reverts" some unknown file (to a "frankenstein"
>> version), it is subsequently committed as a new version by the
>> unsuspecting developer.
>>
>> We've tried exporting and re-importing the code to a new repository, but
>> the issue has persisted. "Svnadmin verify" finds no errors in any
>> revisions. Our latest move was to disable the Windows Search service,
>> but if that's really the problem, our other developers should be seeing
>> this with other repositories. Any advice on how to
>> duplicate/troubleshoot the cause of this problem will be greatly
>> appreciated.
>>
>> Thank you,
>> Dave
>>
> Hi, I've seen something like this before when some of the users were remote nd
> were accessing the repository via a SVK mirror. The mirror was reverting
> files prior to committing to what I presume it thought the state should be.
> This was some years ago, but if I recall correctly the commits for the
> reverted files did not have any commit message. I don't know if it was an
> artifact of the setup we had (I never did the setup) but commits coming via
> the SVK mirror would be from a single user but the real user would be part of
> the commit message. Could something like this be happening for you?
>
> Campbell
>
>
Thanks Campbell. No remote users, no SVK mirror in place, nor anything
intermediate between the server and clients.
-Dave
Re: Random files being "reverted" on one repository
Posted by Campbell Allan <ca...@sword-ciboodle.com>.
On Wednesday 11 May 2011, Dave Tingling wrote:
> Hi List,
>
> We administer subversion (v 1.4.2, r22196 on CentOS 5.5) for a
> development company, and have over 150 active repositories, but we are
> not subversion experts. We are experiencing an issue with just one
> particular repository.
>
> When programmers run an update against this one repository (using either
> TortoiseSVN 1.6.15 or Slik Subversion 1.6.16 on Windows 7 Pro SP1), they
> observe that they sometimes get---to coin their term---"frankenstein"
> versions of arbitrary files. As an example scenario:
>
> 1) - Developer A: adds, edits and commits a file X,
> 2) - Developer A: later, again edits and commits file X,
> 3) - Developer A: still later, again edits and commits file X,
> 4) - Developer N: who has never before seen file X, runs an update. She
> gets a weird version of file X which contains only *some* lines of the
> set of changes made by Developer A in each of the edit/commit sessions
> (1), (2), and (3).
>
> We cannot replicate the problem on demand, but it recurs with
> (seemingly) random files at random times. The worst thing is that when
> an update silently "reverts" some unknown file (to a "frankenstein"
> version), it is subsequently committed as a new version by the
> unsuspecting developer.
>
> We've tried exporting and re-importing the code to a new repository, but
> the issue has persisted. "Svnadmin verify" finds no errors in any
> revisions. Our latest move was to disable the Windows Search service,
> but if that's really the problem, our other developers should be seeing
> this with other repositories. Any advice on how to
> duplicate/troubleshoot the cause of this problem will be greatly
> appreciated.
>
> Thank you,
> Dave
Hi, I've seen something like this before when some of the users were remote nd
were accessing the repository via a SVK mirror. The mirror was reverting
files prior to committing to what I presume it thought the state should be.
This was some years ago, but if I recall correctly the commits for the
reverted files did not have any commit message. I don't know if it was an
artifact of the setup we had (I never did the setup) but commits coming via
the SVK mirror would be from a single user but the real user would be part of
the commit message. Could something like this be happening for you?
Campbell
--
__________________________________________________________________________________
Sword Ciboodle is the trading name of ciboodle Limited (a company
registered in Scotland with registered number SC143434 and whose
registered office is at India of Inchinnan, Renfrewshire, UK,
PA4 9LH) which is part of the Sword Group of companies.
This email (and any attachments) is intended for the named
recipient(s) and is private and confidential. If it is not for you,
please inform us and then delete it. If you are not the intended
recipient(s), the use, disclosure, copying or distribution of any
information contained within this email is prohibited. Messages to
and from us may be monitored. If the content is not about the
business of the Sword Group then the message is neither from nor
sanctioned by us.
Internet communications are not secure. You should scan this
message and any attachments for viruses. Under no circumstances
do we accept liability for any loss or damage which may result from
your receipt of this email or any attachment.
__________________________________________________________________________________