Community
Participate
Working Groups
Yesterday evening (CET) I had committed a fix for bug 315694. This morning I tried to sync on a different machine via pserver, but the change wasn't there. I assume that usually sync'ing between pserver and extssh servers takes less time, so I'm filing this bug.
Szymon has noticed the same thing with a change he made yesterday in *.core.resources.
Ok, looks like the sync got stuck. I've restarted it and it seems happy. Can you confirm that your changes have been copied? -M.
Yep, I can see them now.
*** Bug 338040 has been marked as a duplicate of this bug. ***
These bugs will keep cropping up occasionally until we can find a better way to sync pserver and ssh data. Right now, I don't have any actionable ideas.
*** Bug 335963 has been marked as a duplicate of this bug. ***
This is a bigger issue than changes being there or not. I'm assuming due to the way CVS works that changes to multiple files are not atomic. Therefore what should be a single changeset might be partially out of sync. Worse than that I am seeing files that have changed recently completely missing from the pserver server. This makes it near impossible for a non-committer to track a project with any sort of active development. I have run into this twice today and it is very frustrating. An example if you look quickly: http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.rap/runtime.rwt/org.eclipse.rap.rwt.q07/js/org/eclipse/rwt/?root=RT_Project There should be a file called Border.js which was there in previous versions, but is now nowhere to be found for any version.
> This is a bigger issue than changes being there or not. I'm assuming due to the > way CVS works that changes to multiple files are not atomic. This is correct. > Therefore what > should be a single changeset might be partially out of sync. It *could*; however, the cvs syncer waits for commit activity to cease before launching a sync. > There should be a file called Border.js which was there in previous versions, > but is now nowhere to be found for any version. Border.js is a new file that was created mere hours ago (actually, two minutes prior to the committer's comment on bug 341924), and it only contains the initial commit. Now with that being said, it would appear the cvs syncer is picking up file updates, but not file additions -- which, for the first time, actually gives me something repeatable I can work with. I'll investigate and see why the syncer is missing out on new files.
(In reply to comment #8) > Border.js is a new file that was created mere hours ago (actually, two minutes > prior to the committer's comment on bug 341924), and it only contains the > initial commit. Sorry, I thought Border.js was an existing file. However the file I was having problems with earlier was this one, which definitely has history but was missing completely earlier today: http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.rap/runtime.rwt/org.eclipse.rap.rwt/src/org/eclipse/swt/internal/graphics/ColorUtil.java?root=RT_Project&view=log > Now with that being said, it would appear the cvs syncer is picking up file > updates, but not file additions -- which, for the first time, actually gives me > something repeatable I can work with. I'll investigate and see why the syncer > is missing out on new files. Thanks for taking a loook.
> However the file I was having > problems with earlier was this one, which definitely has history but was > missing completely earlier today: As much as I want to believe that what you're saying is accurate, I have a hard time understanding how files can go missing, to only reappear later, unless it's a result of a back file lock or something similar. If that were the case, I would have thought the problem would be more widespread than it is. If you can, please attach a screenshot of this if you happen to catch something. > Now with that being said, it would appear the cvs syncer is picking up file > updates, but not file additions I'm getting nowhere fast in trying to replicate this. I've created new files, and new files under several new subdirectory levels -- they all get replicated within the prescribed delay of a few seconds.
FWIW, I'm also looking into upgrading our rsync package on the backend servers. The old one that's there now does not support incremental file lists, so it's rather inefficient. I'm thinking that with a more efficient rsync, I'll be able to do complete syncs more frequently and will less overhead on the file system.
This is fixed. We sync fairly often, and the auto-sync has stabilized.
