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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
