I confirm that you git 1.9 for windows now support long path name. Note that you have to enable it with:
git config core.longpaths true for a single repository or git config --global core.longpaths true globally. On Thu, Mar 20, 2014 at 4:25 PM, Thomas Mortagne <[email protected]> wrote: > Note that long path issue on Windows is supposedly fixed in git 1.9. > > On Thu, Jun 20, 2013 at 9:42 AM, Ecaterina Moraru (Valica) > <[email protected]> wrote: >> Linking the issue in case someone will work on this in the future >> http://jira.xwiki.org/browse/XWIKI-8275 >> >> Thanks, >> Caty >> >> On Wed, May 22, 2013 at 1:55 PM, Thomas Mortagne >> <[email protected]>wrote: >> >>> So here are the winners on platform/XE master: >>> >>> >>> xwiki-platform-core/xwiki-platform-administration/xwiki-platform-administration-test/xwiki-platform-administration-test-tests/target/smartgwt/com/smartclient/theme/enterpriseblue/public/sc/skins/EnterpriseBlue/images/Progressbar/progressbar_Disabled_v_empty_stretch.gif >>> (270) >>> >>> >>> xwiki-enterprise-installers/xwiki-enterprise-installer-generic/target/container/xwiki-enterprise-jetty-hsqldb-5.1-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.1-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.1-SNAPSHOT.xed >>> (296) >>> >>> which gives after refactoring >>> >>> >>> core/administration/test/tests/target/smartgwt/com/smartclient/theme/enterpriseblue/public/sc/skins/EnterpriseBlue/images/Progressbar/progressbar_Disabled_v_empty_stretch.gif >>> (174) >>> >>> >>> installers/generic/target/container/xwiki-enterprise-jetty-hsqldb-5.1-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.1-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.1-SNAPSHOT.xed >>> (252) >>> >>> On Tue, May 21, 2013 at 11:54 AM, Vincent Massol <[email protected]> >>> wrote: >>> > FTR Thomas and I have discussed this a bit and one thing Thomas has >>> started checking is the longest path we currently have. >>> > >>> > One that we have found is: >>> > >>> > >>> /Users/vmassol/dev/xwiki/git/xwiki-platform/xwiki-platform-core/xwiki-platform-ircbot/xwiki-platform-ircbot-test/xwiki-platform-ircbot-test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.0.2-SNAPSHOT.xar >>> > >>> >>> Note that this kind of path does not exist, looks like you extracted a >>> XE in your platform project for test purpose. The actual test data is >>> extracted in >>> /Users/vmassol/dev/xwiki/git/xwiki-platform/xwiki-platform-core/xwiki-platform-ircbot/xwiki-platform-ircbot-test/wiki >>> and /data/extension/repository is empty. >>> >>> > That's 375 characters >>> > >>> > With the new rule that would be: >>> > >>> > >>> /Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-5.0.2-SNAPSHOT.xar >>> > >>> > That's still 301 characters. >>> > >>> > Thomas has done an extensive search and he'll be able to give more >>> details on other long paths. >>> > >>> > Also note that we have an issue at runtime with too long paths: >>> > >>> > [2/11/13 1:22:10 PM] Ionut Maxim: ! >>> C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip: The >>> archive is corrupt >>> > ! C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip: >>> The archive is corrupt >>> > ... >>> > ! C:\Users\max\Downloads\xwiki-enterprise-jetty-hsqldb-4.5-rc-1.zip: >>> Cannot create >>> xwiki-enterprise-jetty-hsqldb-4.5-rc-1\data\extension\repository\org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui\4.5-rc-1\org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui-4.5-rc-1.xed >>> > Total path and file name length must not exceed 260 characters >>> > >>> > What we could do to solve both problems would be to reduce the path >>> length used by the EM to store metadata. For example: >>> > >>> > >>> /Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/org.xwiki.platform%3Axwiki-platform-rendering-wikimacro-ui/5.0.2-SNAPSHOT/artifact.xar >>> > >>> > which gives 236 chars. Still pretty close so another solution would be >>> to use some random directory names (since the names are not used by the EM): >>> > >>> > >>> /Users/vmassol/dev/xwiki/git/xwiki-platform/core/ircbot/test/test-tests/target/xwiki-enterprise-jetty-hsqldb-5.0.2-SNAPSHOT/data/extension/repository/dfdsf4fszz3lmbf567/artifact.xar >>> > >>> > which would be around 200 chars. >>> > >>> > Now what would be interesting would be to give indications to xwiki >>> builders and xwiki users as to what is the max path prefix they're allowed >>> to use for xwiki to build/work. In my example below I'm using >>> "/Users/vmassol/dev/xwiki/git" chars (i.e. 28 chars). >>> > >>> > Thanks >>> > -Vincent >>> > >>> > On May 16, 2013, at 7:02 PM, Sergiu Dumitriu <[email protected]> wrote: >>> > >>> >> On 05/16/2013 12:16 PM, Vincent Massol wrote: >>> >>> >>> >>> On May 16, 2013, at 6:09 PM, Vincent Massol <[email protected]> >>> wrote: >>> >>> >>> >>>> >>> >>>> On May 16, 2013, at 5:29 PM, Sergiu Dumitriu <[email protected]> >>> wrote: >>> >>>> >>> >>>>> On 05/16/2013 10:54 AM, Vincent Massol wrote: >>> >>>>>> >>> >>>>>> On May 16, 2013, at 4:47 PM, Thomas Mortagne < >>> [email protected]> wrote: >>> >>>>>> >>> >>>>>>> On Thu, May 16, 2013 at 4:25 PM, Vincent Massol < >>> [email protected]> wrote: >>> >>>>>>>> I'm rather -0 ATM and very close to -1 because: >>> >>>>>>>> >>> >>>>>>>> 1) I haven't heard from a windows dev for a long time, I don't >>> think that happens that often >>> >>>>>>> >>> >>>>>>> And it's surely not going to improve... >>> >>>>>>> >>> >>>>>>>> >>> >>>>>>>> 2) It's a *huge* change and it should definitely not be done >>> lightly. We would need to plan a period like 2 full days, all devs would >>> need to stop working on what they do and help out. For example all pages on >>> xwiki.org having some github links are going to be broken and will need >>> to be updated (that's probably around hunded of pages overall) >>> >>>>>>>> >>> >>>>>>> >>> >>>>>>> Yes it's a huge change, that's why it's a vote. >>> >>>>>>> >>> >>>>>>>> 3) Windows devs have a simple solution which is to use cygwin so >>> it's not a blocker >>> >>>>>>> >>> >>>>>>> It's not as trivial as you seems to think and it also mean that you >>> >>>>>>> simply can't use the standard git tools in the Windows world like >>> the >>> >>>>>>> Github application or Tortoisegit without speaking or any EDI git >>> >>>>>>> integration... so not it really can't be seen as some obvious >>> >>>>>>> solution. And it's not like using Cygwin was some king of standard >>> for >>> >>>>>>> Windows dev. "use cyggwin" is easy to say but the reality is that a >>> >>>>>>> dev will try to clone XWiki repository with the git tool he is >>> used to >>> >>>>>>> and will simply can't, period. >>> >>>>>> >>> >>>>>> What I'm saying is that I don't think it's worth the effort. By >>> worth I mean the ratio between the effort and problems it'll require from >>> us vs the # of windows dev not using cygwin that'll want to develop for the >>> xwiki project... >>> >>>>> >>> >>>>> But this is why we have a democracy and not a dictatorship. If the >>> >>>>> community considers it is worth the effort, and at least some devs >>> are >>> >>>>> willing to work on this, then I think it's their right to do this. >>> >>>> >>> >>>> 1) You should re-read the governance. It's a meritocracy, i.e we vote >>> important changes and devs need to be ok. So if one or a few devs want to >>> do this but some other don't for some valid reason then it's not going to >>> happen until we reach a decision. >>> >>>> >>> >>>> 2) It's all the devs that will bear the cost of maintaining the new >>> environment, no just the dev who's willing to do the initial work. >>> >>>> >>> >>>> BTW none of us work on a windows environment and I think it's a bad >>> idea to implement support for something that we never use. It can only lead >>> to something that gets broken frequently. To overcome this we'd need some >>> windows agent and this means supporting that agent and making sure it works >>> all the time (we tried in the past and failed for a very simple reason: >>> none of the devs use windows and thus we don't care). >>> >>>> >>> >>>>> It's not a good move to veto the will of the community. >>> >>>> >>> >>>> Again (in case you didn't understand) I'm ok on the principle of >>> doing this move but doing cowboy-coding without thinking about the >>> consequences and letting other fix your stuff by only doing half of the >>> work isn't my preferred style... >>> >>>> >>> >>>> We've had enough bad examples of the dev environment being broken for >>> week(s not so long ago that it's normal to want to be careful... >>> >>>> >>> >>>>> Anyway, there are other reasons to make the change, not just Windows >>> >>>>> compatibility. It saves about 2 seconds each time a dev wants to go >>> to a >>> >>>>> directory from the command line. Going into one subdirectory means >>> >>>>> having to press "x tab <right prefix of the submodule> tab". The >>> first >>> >>>>> two keys are superfluous since they're the same all the time. The >>> deeper >>> >>>>> the hierarchy, the longer the time it takes to go there. It adds up >>> to >>> >>>>> more than an hour wasted per year per dev, and I don't think it will >>> >>>>> really take a whole month of every dev to do the migration. If >>> everybody >>> >>>>> contributes and we do a systematic effort, it could be done in an >>> hour >>> >>>>> with the right planning. >>> >>>> >>> >>>> So to reiterate and to be constructive, before we start any actual >>> work on this I'd like that we do more evaluation. This means: >>> >>>> * see a list of windows coders who have expressed a need (apart from >>> Florin who I know already) and who have a real will to participate after >>> the move. Do we have at least one? >>> >> >>> >> This is not just about Windows. The committers that vote +1 vote for >>> >> their own environment, not just to fix a problem for hypothetical >>> >> contributors. >>> >> >>> >> And it's not about improving something for existing contributors, but >>> >> removing a blocker standing in the way of future contributors. The >>> >> easier it is for a new potential community member to join, the more of >>> >> these tentative users will actually stick around. And XWiki isn't >>> >> overwhelmed by the number of contributors to afford to voluntarily keep >>> >> out those not motivated enough to actually try to find out why the >>> >> checkout fails and what needs to be done to actually have a working >>> >> environment and go through all the painful process of installing cygwin >>> >> and the the command line tools that work with cygwin. >>> >> >>> >>>> * that we list what needs to be done precisely. I've identified some >>> so far: >>> >>>> ** the git path changes >>> >>>> ** modify all the xwiki.org pages linking to code >>> >>>> ** git history, will we loose ability to see history of files? >>> >> >>> >> Not really. In some cases we might have to add --find-copies-harder to >>> >> some commands, but it should work out of the box for most files. >>> >> >>> >> Viewing the commits that affect a file on GitHub might not list pre-move >>> >> commits, but the history will s >>> >> >>> >>>> ** others? >>> >> >>> >> * The move will break uncommitted local changes, so all devs should try >>> >> to commit their local changes, at least in a separate local branch if >>> >> not on github. But devs shouldn't keep uncommitted changes anyway, >>> right? >>> >> >>> >> * Depending on how they're configured, our IDEs might freak out when >>> >> pulling for the first time, since everything will be moved around. >>> >> >>> >> * Existing pull request should still work, but Jira patches will break; >>> >> they're probably broken already anyway, since we didn't really allow new >>> >> patches to be put there for a while, and most of the paths have changed >>> >> since 1-2 years ago. >>> >> >>> >> * Does anything on Jenkins depend on paths? I hope not, configurations >>> >> use module names, and they will continue to point to the right POM. >>> >> >>> >> * I guess this still counts as xwiki.org changes, but we should make >>> >> sure the pages that work with remote files, like the syntax >>> >> documentation and syntax completion report, will also need to be >>> updated. >>> >> >>> >> * Existing links in emails (and other places with answers like >>> >> stackoverlow) will be broken, but that already happens whenever we move >>> >> a module, for example to make room for api+ui+test submodules, and this >>> >> happened a lot recently, so it's not a new problem. >>> >> >>> >> * Most annoying: forgetting our own reflex of typing x+tab when changing >>> >> the path :-) >>> >> >>> >>> ** what happens to the JIRA links to commits in the Commits tab? Will >>> they still work? >>> >> >>> >> Yes, the existing commits will not change. >>> >> >>> >>> Thanks >>> >>> -Vincent >>> >>> >>> >>>> * to list who is ok to participate actively in the move >>> >>>> * that we agree on a date so that it doesn't impact our planned >>> roadmap >>> >>>> >>> >>>> Thanks >>> >>>> -Vincent >>> >>>> >>> >>>>>> We're going to loose at least a month before we've finished that >>> migration completely and I'm really worried about the toll it'll have on >>> our releases... >>> >>>>>> >>> >>>>>> Thanks >>> >>>>>> -Vincent >>> >>>>>> >>> >>>>>> PS: With the same group effort we could release a first version of >>> the new model for example ;) >>> >>>>>> >>> > >>> > _______________________________________________ >>> > devs mailing list >>> > [email protected] >>> > http://lists.xwiki.org/mailman/listinfo/devs >>> >>> >>> >>> -- >>> Thomas Mortagne >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
