[xwiki-devs] [VOTE] Move history when moving stuff from repositories of "xwiki" organization
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
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-c...". 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 <[email protected]>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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Feb 28, 2012 at 1:17 PM, Thomas Mortagne <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
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.
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.
* 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.
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. 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
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.
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, 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 <[email protected]> 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.
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.
* 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.
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. 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
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.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
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
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 <[email protected]> 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
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 <[email protected]>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 <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 <[email protected]> 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/
On Wed, Mar 7, 2012 at 3:14 PM, Sergiu Dumitriu <[email protected]> wrote:
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
Thanks, looks nice. Trying it.
On Tue, Feb 28, 2012 at 12:17 PM, Thomas Mortagne <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (6)
-
Denis Gervalle -
Eduard Moraru -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol