On Mar 2, 2012, at 10:06 AM, Denis Gervalle wrote: > On Wed, Feb 29, 2012 at 08:19, Vincent Massol <[email protected]> wrote: > >> Hi, >> >> On Feb 28, 2012, at 12:17 PM, Thomas Mortagne wrote: >> >>> Hi devs, >>> >>> Since I plan to move some stuff from platform to commons I would like >>> to know what you think of the history in this case. >>> >>> Pros including history: >>> * can access easily the whole history of a moved file. >> > > This is really an important matter, especially for those joining the > project. When you follow XWiki from "outside", and not in a continuous > manner, the history is of great value to understand why stuffs are like > they are, and what you may do, or not when moving forward.
The history is not lost. If you do a join (all active repos) you still have it. >> But sometimes >>> changing packages etc make too much difference for git to see it's >>> actually the same file so you loose it anyway. >> > > If you simply change the package name, and nothing else, it is really > unlikely to happen. > > >>> >>> Cons including history: >>> * double the history which make tools like ohloh indicate wrong >> informations >> > > Sure, the stats will be broken, but what is the matter. This is not > cheating, just a misfeature in Ohloh, since the commit are just identical, > something they may notice. IMO, this is the matter of the statistical tools > to improve that. Can you tell me how to implement this because right now my GitHub tool doesn't do that and I don't know how to do it? >>> * it's a lot easier to move without history >> > > There should be some tools to improve that point or we may write one, once > for all. So this is not a real cons either. It's really hard to copy history in Git. It's almost impossible to do it right. You have to remember the full history and it's just too hard. >>> WDYT ? >>> >>> Even if it was looking a bit weird to me at first I'm actually +1 to >>> not move the history in this case. >> >> +1, FTR I'd be -0, close to -1 to move it. If/when the source repository >> is removed for one reason or another, then we might want to import its >> history somewhere. >> > > Seems we are really opposite on this one, since I am close to -1 to not > move it. Sorry but that's the current practice :) It's also the easiest one. > Statistics is really less valuable IMO, it is a small interest compare to > code history, that I have use a lot, especially when I have join the > project and follow sparingly. I can say exactly the same thing as you said above. It's just a question of tools since the history is not lost. It's still there in our active repos. > So the general rule for me is: Copy history when the source repository is >> removed/deleted/not used anymore. How many times have you done this? I believe 0 times since I don't think you'd be so much in favor if you had tried it. I suggest you try it a few times on your own projects first :) It's really hard to do it right and very time consuming. > You never know what will happen to a repository in the future, so this > rules is somewhat a hope on the future, no more. And remembering that we > may loose history if we do some change in the old repository, is for me > like hoping you will remember my birthday ;) I don't agree with this at all. Again we're not loosing history. If a repo is removed then its history is copied I agree about that. >>> Eduard was proposing to include in the first commit of the new >>> repository the id of the last commit containing the files (basically >>> the id of the parent of the commit deleting the files) in the old >>> repository so that it's easier to find it. I'm +1 for this. >> > > But you loose all the benefits of the IDE tools that brings history of a > selection automatically and that are really useful. A huge majority of xwiki's history is already lost to IDEs (when we moved from SVN) even though the SVN history was moved. Even Git itself doesn't follow the history when you move stuff around. Said differently it's alwasy possible to find the history but the IDE and "standard" tool don't follow it. > Moreover, if the history is rewritten due to a change in structure later, > the hash may be broken. Not sure I understand this one. You should really measure the cost of what you propose Denis. It's really hard to do. Thanks -Vincent > So having a broken history is hardening the task of those who want to > participate. A great value compare to the statistics IMO. > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
