[xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization
28 Feb
2012
28 Feb
'12
12:17 p.m.
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
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.
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.
--
Thomas Mortagne
28 Feb
28 Feb
1:05 p.m.
New subject: [xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization
Hi Thomas,
Thanks for starting this thread.
Not copying the history and just linking in the commit message to the old
repository only works if you have the guarantee that the old repository
will not get deleted or assimilated into another, rewriting history.
Or better yet, what happens if, in 2 years we switch to a new versioning
tool with its own optimum layout? I`m looking at commits from SVN that are
now moved to git and they all have a commit message like "git-svn-id:
https://svn.xwiki.org/svnroot/xwiki/xwiki-platform/core/trunk@9889f329d543-…quot;.
Having an SVN revision number it is
not trivial to obtain the GIT hash corresponding to the commit; and you
have to do this from the command line.
Isn't this a bit risky on the long run?
P.S.: If we do decide that not copying history is ok, here's my big +1 to
at least mentioning in the commit log in the new repository the parent
commit from the old repository.
Thanks,
Eduard
On Tue, Feb 28, 2012 at 1:17 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;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. But sometimes
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.
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.
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
29 Feb
29 Feb
7:59 a.m.
New subject: [xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization
On Tue, Feb 28, 2012 at 1:17 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> 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. But sometimes
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
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.
+1
Thanks,
Marius
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:19 a.m.
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. But sometimes
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.
So the general rule for me is: Copy history when the source repository is
removed/deleted/not used anymore.
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.
+1
Thanks
-Vincent
2 Mar
2 Mar
10:06 a.m.
New subject: [xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization
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
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.
5 Mar
5 Mar
5:33 p.m.
New subject: [xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization
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.
9 Mar
9 Mar
5:58 p.m.
On Mar 2, 2012, at 10:06 AM, Denis Gervalle 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.
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?
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.
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.
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.
On Wed, Feb 29, 2012 at 08:19, Vincent Massol
<vincent(a)massol.net> wrote:
The history is not lost. If you do a join (all active repos) you still have it.
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.
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:48 p.m.
For the record I'm currently -1 to copy the history. I'm mentioning because thomas
has just copied the history from platform to commons and I don't want this to happen
again till we close this VOTE.
As of now it's been our practice to not copy the history between our active repos
(commons, rendering, platform, enterprise, etc) so we shouldn't copy them until the
VOTE is passed.
Thanks
-Vincent
On Feb 29, 2012, at 8:19 AM, Vincent Massol 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. But sometimes
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.
So the general rule for me is: Copy history when the source repository is
removed/deleted/not used anymore.
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.
+1
Thanks
-Vincent
7 Mar
7 Mar
noon
New subject: [xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization
I'm doing some experiment and here is another issue: the common way to
isolate a subproject history is by using git filter-branch
--subdirectory-filter which isolate history based on the provided path
but this obviously is blocked by any modification on this path. In
practice it mean that no history older than the refactoring made when
we moved to git will be kept (and sometime even worst if other change
have been made).
Any other idea to isolate history ?
On Tue, Feb 28, 2012 at 12:17 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> 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. But sometimes
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.
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.
--
Thomas Mortagne
--
Thomas Mortagne
1:27 p.m.
New subject: [xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization
Sergiu has some experience with this. Maybe he knows some best practices or
ways to preserve full history (including git renames).
Thanks,
Eduard
On Wed, Mar 7, 2012 at 1:00 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
I'm doing some experiment and here is another
issue: the common way to
isolate a subproject history is by using git filter-branch
--subdirectory-filter which isolate history based on the provided path
but this obviously is blocked by any modification on this path. In
practice it mean that no history older than the refactoring made when
we moved to git will be kept (and sometime even worst if other change
have been made).
Any other idea to isolate history ?
On Tue, Feb 28, 2012 at 12:17 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> 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. But sometimes
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.
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.
--
Thomas Mortagne
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:14 p.m.
New subject: [xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization
On 03/07/2012 06:00 AM, Thomas Mortagne wrote:
I'm doing some experiment and here is another
issue: the common way to
isolate a subproject history is by using git filter-branch
--subdirectory-filter which isolate history based on the provided path
but this obviously is blocked by any modification on this path. In
practice it mean that no history older than the refactoring made when
we moved to git will be kept (and sometime even worst if other change
have been made).
Any other idea to isolate history ?
Yep, I've been using filter-branch with --index-filter and a sed-based
rewriting of paths so that I keep track of all the previous locations of
a module, rewriting to a common path at the same time. It takes some
time to track down the history of a module, especially when it has been
extracted from another module at some point.
I've put a stub at https://gist.github.com/1993357
On Tue, Feb 28, 2012 at 12:17 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> 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. But sometimes
> 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.
>
> 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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
3:25 p.m.
New subject: [xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization
On Wed, Mar 7, 2012 at 3:14 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
--
Thomas Mortagne
On 03/07/2012 06:00 AM, Thomas Mortagne wrote:
Thanks, looks nice. Trying it.
I'm doing some experiment and here is another issue: the common way to
isolate a subproject history is by using git filter-branch
--subdirectory-filter which isolate history based on the provided path
but this obviously is blocked by any modification on this path. In
practice it mean that no history older than the refactoring made when
we moved to git will be kept (and sometime even worst if other change
have been made).
Any other idea to isolate history ?
Yep, I've been using filter-branch with --index-filter and a sed-based
rewriting of paths so that I keep track of all the previous locations of a
module, rewriting to a common path at the same time. It takes some time to
track down the history of a module, especially when it has been extracted
from another module at some point.
I've put a stub at https://gist.github.com/1993357 On Tue, Feb 28, 2012 at 12:17 PM, Thomas
Mortagne
<thomas.mortagne(a)xwiki.com> 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. But sometimes
> 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.
>
> 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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4574
days inactive
4584
days old
11 comments
6 participants
participants (6)
-
Denis Gervalle -
Eduard Moraru -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol