5 Mar
2012
5 Mar
'12
5:33 p.m.
Hi,
Denis did a better job than me in detailing his concerns. I share the same
opinion with him that history is much more important then statistics tools.
Thanks,
Eduard
On Fri, Mar 2, 2012 at 11:06 AM, Denis Gervalle <dgl(a)softec.lu> wrote:
On Wed, Feb 29, 2012 at 08:19, Vincent Massol
<vincent(a)massol.net> wrote:
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.
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.
Seems we are really opposite on this one, since I am close to -1 to not
move it.
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.
So the general rule for me is: Copy history when the source repository is
But you loose all the benefits of the IDE tools that brings history of a
selection automatically and that are really useful.
Moreover, if the history is rewritten due to a change in structure later,
the hash may be broken.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi,
On Feb 28, 2012, at 12:17 PM, Thomas Mortagne wrote:
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.
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.
But sometimes
If you simply change the package name, and nothing else, it is really
unlikely to happen.
changing packages etc make too much difference
for git to see it's
actually the same file so you loose it anyway.
Cons including history:
* double the history which make tools like ohloh indicate wrong
informations
*
it's a lot easier to move without history
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.
removed/deleted/not used anymore.
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 ;)
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.