[Bug 170667] Files that prevent full SVN Checkouts

[Mark]

http://bugs.kde.org/show_bug.cgi?id=170667


Mark Ziggyesque hotmail com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|WORKSFORME                  |




--- Comment #5 from Mark <Ziggyesque hotmail com>  2008-11-26 07:35:54 ---
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


-- 
Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.