git add --interactive On 07/27/2016 03:59 AM, Alexandru Cotiuga wrote: > I'm +1 for not committing date changes and it would be helpful to ignore > them at some point, since I need all the time to edit files to commit in > order to revert date changes. > > Thanks, > Alex > > On Mon, Jul 25, 2016 at 10:40 PM, Thomas Mortagne <thomas.morta...@xwiki.com >> wrote: > >> Le 25 juil. 2016 18:31, "Vincent Massol" <vinc...@massol.net> a écrit : >>> >>> >>>> On 25 Jul 2016, at 18:20, Eduard Moraru <enygma2...@gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> On Mon, Jul 25, 2016 at 6:46 PM, Vincent Massol <vinc...@massol.net> >> wrote: >>>> >>>>> I think I’d be in favor of: >>>>> * Have our xar:format remove the dates >>>>> * Have xar:verify fail if the dates are in the XML (thus our quality >> build >>>>> will fail if that’s the case) >>>>> * Have the import set the current date if no dates are defined (that’s >>>>> probably the case already, would need to be checked) >>>>> >>>> >>>> A side-effect of this is that, when you upgrade and extension, all the >>>> pages of the extension will be changed and set to the update date as >> their >>>> last modification dates, right? (i.e. it affects both fresh installs >> and >>>> upgrades) >>> >>> Isn’t this what happens now already, i.e. when an existing page is >> imported the current date is set (unless it’s a backup pack)? >> >> Yes EM does not take into account plumbing stuff like date and version. >> >>> >>> If the issue is about the diff, I guess we could have a diff that doesn’t >> take into account the dates (or a better algorithm could be to not update a >> page that only has the date metadata modified). >> >> It's already the case... >> >>> >>>> Thinking more about it, it could be problematic for all the pages of an >>>> extension that you upgrade to appear as being modified, even if nothing >>>> changed in them in that particular version. >>> >>> We should definitely not update pages with no changes. >>> >>>> Another minor negative side-effect would also be searching or listing >>>> documents and sorting them by the last update time. Of course, this >> would >>>> mostly affect admins or users with "show hidden documents" enabled. >>> >>> I we don’t update pages that haven’t been changed we won’t have this >> problem, right? >>> >>>> However, if you happen to also manage some content pages in your build >>>> (that are not supposed to be hidden), this becomes a nuissance. >>>> >>>> WDYT about the 2 problems? I guess we could always accept them and say >> that >>>> installs/upgrades are relatively rare and that the impact is minimal >> (and >>>> similar to an empty save in a document - something that can already be >>>> observed in practice in a document's history - so we don`t introduce >>>> anything new). >>>> >>>> Thanks, >>>> Eduard >>>> >>>> P.S.: Here`s an existing issue more or less related to this topic >>>> http://jira.xwiki.org/browse/XWIKI-7058. Caty reminded me about it. >>> >>> And http://jira.xwiki.org/browse/XWIKI-11764 >>> >>> Thanks >>> -Vincent >>> >>>> * Have AS and Watchlist exclude import / new wiki (already the case) >>>>> >>>>> Thanks >>>>> -Vincent >>>>> >>>>>> On 25 Jul 2016, at 14:08, Eduard Moraru <enygma2...@gmail.com> >> wrote: >>>>>> >>>>>> Hi, devs, >>>>>> >>>>>> This interesting discussion [1] came up recently on a github commit >> that >>>>>> lead us to realise that a practice which we have been doing since >> forever >>>>>> is not documented in our best practices guides and that we also seem >> to >>>>>> lack consensus on it. >>>>>> >>>>>> It`s about the practice of skipping date field changes from document >> XML >>>>>> pages when committing them to source control. This includes doc date >>>>>> and contentUpdateDate >>>>>> fields, but also attachment dates. >>>>>> >>>>>> You can see some arguments on the discussion[1], but I also wanted to >>>>>> mention that this practice goes in line with what we do for document >>>>>> versions (which is handled by the xar:format maven plugin goal which >> we >>>>>> execute every time, before committing XML pages). If we are to update >> doc >>>>>> dates, then we should also increment doc versions, otherwise it does >> not >>>>>> make any sense. >>>>>> >>>>>> The idea was, AFAIR, that XWIki`s code pages should not generate any >>>>>> updates in the user`s wiki content, in any way, and that and update >> of >>>>> the >>>>>> code of a "system"/XWiki page should not show up as an update of *the >>>>>> user's content*, since it would otherwise confuse him. >>>>>> >>>>>> What we are currently missing from xar:format is exactly this: the >> reset >>>>> of >>>>>> XML page dates to have a clearer and more consistent date for XWiki`s >>>>> code >>>>>> pages. >>>>>> >>>>>> Your input is appreciated and the result of this discussion would be >> the >>>>>> update of our Development Practices [2] and Application Development >> Best >>>>>> Practices [3] pages. >>>>>> >>>>>> Thanks, >>>>>> Eduard >>>>>> >>>>>> ---------- >>>>>> [1] >>>>>> >>>>> >> >> https://github.com/xwiki/xwiki-platform/commit/1938dd18e1d25b8c03e4cb22286273bffdea5530#commitcomment-18375907 >>>>>> [2] >> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices >>>>>> [3] >>>>>> >>>>> >> >> http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPractices >>>>>> _______________________________________________ >>>>>> devs mailing list >>>>>> devs@xwiki.org >>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>>> _______________________________________________ >>>>> devs mailing list >>>>> devs@xwiki.org >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>> _______________________________________________ >>>> devs mailing list >>>> devs@xwiki.org >>>> http://lists.xwiki.org/mailman/listinfo/devs >>> >>> _______________________________________________ >>> devs mailing list >>> devs@xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> devs@xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
