Version: (using Devel) OS: MS Windows Installed from: Compiled sources Since KDE is advertising the capability to be compiled under Windows starting with Ver. 4, I feel these count as errors in the repository. These files have colons in name which are illegal for Windows filesystems, and *nix shell path separators, and crash SVN when encountered during a Checkout or Update on Windows: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebindings/python/pykde4/docs/html/phonon/Phonon::BackendCapabilities.Notifier.html svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebindings/python/pykde4/docs/html/kparts/KParts::Plugin.PluginInfo.html svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebindings/python/pykde4/docs/html/kdecore/KCoreConfigSkeleton::ItemEnum.Choice.html svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebindings/python/pykde4/docs/html/kio/KIO::NetRC.AutoLogin.html svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebindings/python/pykde4/docs/html/kio/KIO::RenameDialogPlugin.FileItem.html Author: sedwards svn://anonsvn.kde.org/home/kde/trunk/playground/artwork/oooicons/crystalsvg/sheetcellcolor:svg.svg Author: pinheiro svn://anonsvn.kde.org/home/kde/trunk/playground/artwork/dekorator/themesStuff/The K-style: Infinity-theme.tar.gz Author: cfeck svn://anonsvn.kde.org/home/kde/trunk/playground/base/kdetestscripts/todo Author: hindenberg, is deletable precursor of svn://anonsvn.kde.org/home/kde/trunk/playground/base/kdetestscripts/TODO Author: bmeyer svn://anonsvn.kde.org/home/kde/trunk/extragear/utils/kdiff3/kdiff3.kdevelop is deletable duplicate of svn://anonsvn.kde.org/home/kde/trunk/extragear/utils/kdiff3/KDiff3.kdevelop Author: joachim These also break SVN due to Windows considering them duplicate filenames. These may not be all of them, they're just what showed up trying to check out some subdirectories of /trunk to a NTFS partition using TortoiseSVN 1.5.2, with multiple seperate checkouts required to get the files that don't have naming problems. Fixing requires changing the filenames to be Windows compatible if they're to be retained and updating all references to them in whatever other files require it. Authors fields taken from the SVN commit handles for each file, which may be used to assign who should fix each instance. Mark
Thanks to pinheiro for fixing his..... one down, 30 or so more to go. Additional files with problems, after entire checkout of /trunk except for /l10n-kde3/ : svn://anonsvn.kde.org/home/kde/trunk/dot.kde.org/static/content/kde-ooo-interview/imonitor.nethost.cz/content/akcejs.php?c=202 plus too many similar under /kde-ooo-interview/ to list svn://anonsvn.kde.org/home/kde/trunk/www/international/netherlands/frysk/INDEX.html svn://anonsvn.kde.org/home/kde/trunk/www/international/netherlands/frysk/index.html svn://anonsvn.kde.org/home/kde/trunk/www/international/netherlands/frysk/nederlands/INDEX.html svn://anonsvn.kde.org/home/kde/trunk/www/international/netherlands/frysk/nederlands/index.html Delete the older INDEX.html ones, it appears goossens forgot to. svn://anonsvn.kde.org/home/kde/trunk/www/sites/developer/documentation/tutorials/howto/developer-HOWTO.pdf svn://anonsvn.kde.org/home/kde/trunk/www/sites/developer/documentation/tutorials/howto/developer-howto.pdf think developer-howto.pdf bogus svn://anonsvn.kde.org/home/kde/trunk/www/sites/api/3.0-api/classref/kfile/KFILE.html svn://anonsvn.kde.org/home/kde/trunk/www/sites/api/3.0-api/classref/kfile/KFile.html svn://anonsvn.kde.org/home/kde/trunk/www/sites/api/3.0-api/classref/kfile/full-list-KFILE.html svn://anonsvn.kde.org/home/kde/trunk/www/sites/api/3.0-api/classref/kfile/full-list-KFile.html suggest rename KFILE.html to KFILE_.html, full-list-KFILE.html to full-list-KFILE_.html svn://anonsvn.kde.org/home/kde/trunk/www/areas/extragear/apps/kst/handbook/Screenshot-kst-view-label-latex-gamma.png svn://anonsvn.kde.org/home/kde/trunk/www/areas/extragear/apps/kst/handbook/Screenshot-kst-view-label-latex-Gamma.png suggest rename Screenshot-kst-view-label-latex-Gamma.png to Screenshot-kst-view-label-latex-g_amma.png, edit view-types.html accordingly svn://anonsvn.kde.org/home/kde/trunk/www/areas/l10n/teams/tr/resimler/bg.png svn://anonsvn.kde.org/home/kde/trunk/www/areas/l10n/teams/tr/resimler/BG.png svn://anonsvn.kde.org/home/kde/trunk/www/areas/l10n/teams/tr/resimler/kde.png svn://anonsvn.kde.org/home/kde/trunk/www/areas/l10n/teams/tr/resimler/KDE.png Mark
I'd appreciate when someone that does fix some or all of these errors finishes, they annotate here which directories did get fixed. Presently all these directories have to be Ignored, and unpopulated, so that SVN Update succeeds and the update process in this circumstance won't report that any possible legitmate changes to other files in those dirs or subdirs are pending, or fetch them. I don't have commit access to the repository, so I can't do it. TIA, Mark
Anybody looking at these???
I don't see a reason why we should fix it. Also I don't know how to fix them as we don't have any insight in these packages. When someone needs them on windows he has to fix them by their own. Currently nobody from kde-windows needs them so they're unlikly to be fixed by us.
Thank you for providing some response, Christian, but... > When someone needs them on windows he has to fix them by their own. Currently nobody from kde-windows needs them so they're unlikly to be fixed by us. That's the point... if it needs "fixing" by anyone, it's a bug, isn't it? Fixes of this nature count as forks, not just branches, if they have to be done piecemeal, and there's no guarantee a file renamed in one fork will have the same rename in any others. I don't expect you're the one to do it, as it doesn't appear any were committed by you or other kde-windows team members, but this doesn't mean it shouldn't get done, I'd think. Your interest for the future is so you don't have to keep fielding questions of the "My compile attempt from SVN doesn't work, but I did all the instructions properly and checked out what it let me" variety, and 'currently' doesn't mean you won't ever run into it on your checkouts in the future. The instructions certainly don't say "On Windows you can do checkouts, but don't try to do it for this dir, and that dir, and maybe this other one; if you want to work on the files there you need a n*x environment and can't use MSVC unless you get it to install under WINE. Also, this list of 'directories you can't checkout' subject to change every time somebody on a n*x box does a commit." Doesn't Affect Me Now isn't the same as Works For Me, it's more you've Verified the bug by this response. I wouldn't be surprised some of the source zip packages already being downloaded have their own errors where the wrong unpacked file will overwrite the correct one, or not unpack at all. So far, given the config.txt thing, I've just tried to install the binaries, figuring the SVN would be more up-to-date anyways. I should have qualified 'Anybody' with 'that can fix them', I guess. I do provide suggestions for a number of them, so is mostly a matter of doing a 'Find in Files...' to locate which references need to be changed in other files. Regressions against wildcard based references will take a more intimate knowlege to process quickly, I imagine, and the changes will have to be done in some branches too. At the least, all the packages which the installer supports now and is planned to support should be fixed, IMO, like kdebindings, playground, and extragear. As SVN doesn't guarantee which order it will check out files, the rest should be done too, or moved into a separate repository. Given the number is pretty small, actually, compared to the number of files in the repository, fixing will take less time. Once done, I think there's a pre-commit script already written that can reject casing and reserved identifier and punctuation conflicts to keep the repository suitable for both types of filesystem. There's the converse problem, after all, that some localized filenames on windows may translate, without filtering, to characters not allowed in the locale the server is running in. Better to let a committer know before it causes problems for all n*x folks too. It's a nuisance, yes, this first step, as it's doubtful a lot of the files listed will have any future content changes again, but better fixed now than assume ALL committers in the future won't introduce new forks, whatever environment they use, that may cause crashes to worse than just SVN. If the individual committers can't/won't do the fixes, I'd think the SVN Admin would be the one to take this on, as they'd have to install the filter anyways. That this is a known problem/possibility with any multiple filesystem project, or even just multiple locales on one filesystem, I'm surprised no one before me has brought this up so it can be addressed systemically. People typo, or forget another system functions just a bit differently; it's not a problem that will disappear on its own with the current varieties of filesystems. That there are so few files with problems shows most aren't exacerbating the problem, conciously or by accident, but there being any at all shows it's not being prevented either. I could bring up other alternatives to this sort of fix, but they all have the detraction of cutting down on the pool of potential developers and maintainers, in that not everyone has the resources to access multiple environments. Hopefully this gets assigned soon, not left in limbo, Mark
will close this bug as it is simply to old. If there is still need for it, please just reopen it.
This is not unmaintained, it's waiting on someone with repository commit access to assign themselves to providing the fixes. Saying it's not a problem because it hasn't affected another portion of the project is NOT fixing it. I expect by this time the problem has migrated into the GIT repositories too, for some files. I'd have done it months ago, but I ~don't~ have commit access.