Hello,
When I look a the JVCL page (which I manage), the analysis says that I left the project last year and that the last commit occurred in March 2011. I'm very surprised because both these statements are wrong. Apparently there was a failure 11 months ago at step 3. Could someone look at what might be wrong here?
Olivier,
We are experiencing an "Inconsistent line ending style" error in the repository that is preventing our update. There are administrative tools to repair this error and if you need additional information or the details of specifically what file failed, I'd be glad to e-mail them to you.
Thanks!
Thanks for your answer. Yes, please send me the details about which files are giving you this error, because AFAIK, those issues were resolved quite a while ago.
Regards Olivier
Olivier,
Will do. Depending on how the issues were resolved, the fix may already be in place. I will try to re-fetch the repository right now and also send on the details in an e-mail in case the re-fetch fails.
Thanks!
Olivier,
Re-fetch did fail at the same point... Let me know if you have any questions.
Thanks!
Thanks for your update. I have read your email and while I understand the solution, I find it difficult to apply because the repository is huge and is hosted at sourceforge. Doing it once should be feasible, but I suspect there are quite a few instances for this "unconsistent line ending" problem. Isn't there a way to simply ignore the offending revision?
Regards Olivier
Olivier,
The only thing we could offer is the "Ignored Files Settings" on the enlistment page. The problem is that setting doesn't take effect until the next successful update. If that weren't the case, we could use that facility to remove the single file (or whole directory) from scrutiny.
We don't have a provision to ignore a specific revision, however.
Let me know.
Thanks!
Thing is, would it be the only revision, I'd take the time to do the whole "dump/fix/reload" cycle. But I'm convinced this has happened numerous times in the history. How do you detect that a given revision has this problem?
For now, if you can ignore that file and have the update go to its end, I'm fine with it.
Olivier,
The only way we know that the problem exists is when the process fails. You are quite correct that each iteration of "dump/fix/reload" will only solve one Inconsistent line ending style error and if multiple errors exist, the solution is rinse and repeat. It's a fundamental issue with Subversion's command which fails when you request a "svn cat" on a file with Inconsistent line endings. We do this constantly while parsing a subversion repository. Unfortunately, the "Ignored Files Settings" is only honored after the next update which completes successfully. Catch-22!
Alternatively, the repository can be imported to a different (hopefully free) repository with another manager (currently Git is our best performer) but it would need to be updated regularly to keep the statistics current. I have no idea if that would be possible.
Things to think about...
Thanks!
So, to detect which files and which revisions are problematic, I should run "svn cat" in a loop and see which ones fail?
Olivier,
I think that would work to discover the troubled ones. I can give you the exact command we use if that would help. I'll e-mail it to you if it would be useful. I presume the return code would show the state of the command but I'm not a programmer and I also presume this would take a really long time to run for all files/revisions...
Thanks!
Olivier,
Re-fetch finished OK (13154 commits). A full update started immediately and also finished OK. Analysis page is now at Mar 28 2012 and last commit is at 2012-03-22.
Please be sure you remind me here if the project stalls again.
Thanks for your enormous patience!
Excellent, looks much better now, thanks for your support.
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.