You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Dawid Weiss (JIRA)" <ji...@apache.org> on 2015/12/16 14:48:46 UTC
[jira] [Updated] (LUCENE-6933) Create a (cleaned up) SVN history in
git
[ https://issues.apache.org/jira/browse/LUCENE-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dawid Weiss updated LUCENE-6933:
--------------------------------
Description:
Goals:
* selectively drop projects and core-irrelevant stuff:
** {{lucene/site}}
** {{lucene/nutch}}
** {{lucene/lucy}}
** {{lucene/tika}}
** {{lucene/hadoop}}
** {{lucene/mahout}}
** {{lucene/pylucene}}
** {{lucene/lucene.net}}
** {{lucene/old_versioned_docs}}
** {{lucene/openrelevance}}
** {{lucene/board-reports}}
** {{lucene/java/site}}
** {{lucene/java/nightly}}
** {{lucene/dev/nightly}}
** {{lucene/dev/lucene2878}}
** {{lucene/sandbox/luke}}
** {{lucene/solr/nightly}}
* preserve the history of all changes to core sources (Solr and Lucene).
** {{lucene/java}}
** {{lucene/solr}}
** {{lucene/dev/trunk}}
** {{lucene/dev/branches/branch_3x}}
** {{lucene/dev/branches/branch_4x}}
** {{lucene/dev/branches/branch_5x}}
* provide a way to link git commits and history with svn revisions (amend the log message).
* annotate release tags
* deal with large binary blobs (JARs): keep empty files instead for their historical reference only.
Non goals:
* no need to preserve "exact" merge history from SVN (see "impossible" below).
* Ability to build ancient versions is not an issue.
Impossible:
* It is not possible to preserve SVN "merge history" because of the following reasons:
** Each commit in SVN operates on individual files. So one commit can "copy" (and record a merge) files from anywhere in the object tree, even modifying them along the way. There simply is no equivalent for this in git.
** There are historical commits in SVN that apply changes to multiple branches in one commit ({{r1569975}}).
* Because exact merge tracking is impossible then what follows is that exact "linearized" history of a given file is also impossible to record. Let's say changes X, Y and Z have been applied to a branch of a file A and then merged back. In git, this would be reflected as a single commit flattening X, Y and Z (on the target branch) and three independent commits on the branch. The "copy-from" link from one branch to another cannot be represented because, as mentioned, merges are done on entire branches in git, not on individual files. Yes, there are commits in SVN history that have selective file merges (not entire branches).
was:
Goals:
- selectively drop unnecessary stuff from history (cms/, javadocs/, JARs and perhaps other binaries),
- *preserve* history of all core sources. So svn log IndexWriter has to go back all the way back to when Doug was young and pretty. Ooops, he's still pretty of course.
- provide a way to link git history with svn revisions. I would, ideally, include a "imported from svn:rev XXX" in the commit log message.
- annotate release tags and branches. I don't care much about interim branches -- they are not important to me (please speak up if you think otherwise).
Non goals
- no need to preserve "exact" history from SVN (the project may skip JARs, etc.). Ability to build ancient versions is not an issue.
> Create a (cleaned up) SVN history in git
> ----------------------------------------
>
> Key: LUCENE-6933
> URL: https://issues.apache.org/jira/browse/LUCENE-6933
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Dawid Weiss
> Assignee: Dawid Weiss
>
> Goals:
> * selectively drop projects and core-irrelevant stuff:
> ** {{lucene/site}}
> ** {{lucene/nutch}}
> ** {{lucene/lucy}}
> ** {{lucene/tika}}
> ** {{lucene/hadoop}}
> ** {{lucene/mahout}}
> ** {{lucene/pylucene}}
> ** {{lucene/lucene.net}}
> ** {{lucene/old_versioned_docs}}
> ** {{lucene/openrelevance}}
> ** {{lucene/board-reports}}
> ** {{lucene/java/site}}
> ** {{lucene/java/nightly}}
> ** {{lucene/dev/nightly}}
> ** {{lucene/dev/lucene2878}}
> ** {{lucene/sandbox/luke}}
> ** {{lucene/solr/nightly}}
> * preserve the history of all changes to core sources (Solr and Lucene).
> ** {{lucene/java}}
> ** {{lucene/solr}}
> ** {{lucene/dev/trunk}}
> ** {{lucene/dev/branches/branch_3x}}
> ** {{lucene/dev/branches/branch_4x}}
> ** {{lucene/dev/branches/branch_5x}}
> * provide a way to link git commits and history with svn revisions (amend the log message).
> * annotate release tags
> * deal with large binary blobs (JARs): keep empty files instead for their historical reference only.
> Non goals:
> * no need to preserve "exact" merge history from SVN (see "impossible" below).
> * Ability to build ancient versions is not an issue.
> Impossible:
> * It is not possible to preserve SVN "merge history" because of the following reasons:
> ** Each commit in SVN operates on individual files. So one commit can "copy" (and record a merge) files from anywhere in the object tree, even modifying them along the way. There simply is no equivalent for this in git.
> ** There are historical commits in SVN that apply changes to multiple branches in one commit ({{r1569975}}).
> * Because exact merge tracking is impossible then what follows is that exact "linearized" history of a given file is also impossible to record. Let's say changes X, Y and Z have been applied to a branch of a file A and then merged back. In git, this would be reflected as a single commit flattening X, Y and Z (on the target branch) and three independent commits on the branch. The "copy-from" link from one branch to another cannot be represented because, as mentioned, merges are done on entire branches in git, not on individual files. Yes, there are commits in SVN history that have selective file merges (not entire branches).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [jira] [Updated] (LUCENE-6933) Create a (cleaned up) SVN history in
git
Posted by Upayavira <uv...@odoko.co.uk>.
One project can have multiple git repos. Apparently there's one or
more with 100+ repos, so all is good there if pylucene wants to shift
to git also.
Upayavira
On Wed, Dec 16, 2015, at 09:48 PM, Dawid Weiss wrote:
>
>> I personally don't care. Git has been a non-issue in PyLucene.
>>
It can move with Lucene or stay in SVN, either way is fine by me.
>
> I don't see a problem with it staying in SVN, we'd just clean up dev,
> much like it has been done before when Solr and Lucene were merged (in
> fact, this is what you see in the git mirror, all the earlier history
> is discarded).
>
> Dawid
>
Re: [jira] [Updated] (LUCENE-6933) Create a (cleaned up) SVN history
in git
Posted by Dawid Weiss <da...@gmail.com>.
> I personally don't care. Git has been a non-issue in PyLucene.
> It can move with Lucene or stay in SVN, either way is fine by me.
I don't see a problem with it staying in SVN, we'd just clean up dev, much
like it has been done before when Solr and Lucene were merged (in fact,
this is what you see in the git mirror, all the earlier history is
discarded).
Dawid
Re: [jira] [Updated] (LUCENE-6933) Create a (cleaned up) SVN history
in git
Posted by Andi Vajda <os...@ovaltofu.org>.
On Wed, 16 Dec 2015, Dawid Weiss wrote:
> We can't touch Apache's SVN so it definitely stays! :)
>
> This was also something that crossed my mind -- we effectively have
> multiple separate projects in one git repo. While it's something SVN can
> take, it's a more problematic issue with git. I don't know if one Apache
> project can have multiple git repos, but I'd assume it'd be a natural way
> out for pylucene? I can also include it in the git repo, of course, but I'd
> opt for having a separate branch for it (one that is orphaned from actual
> Lucene code).
I personally don't care. Git has been a non-issue in PyLucene.
It can move with Lucene or stay in SVN, either way is fine by me.
Andi..
>
> Dawid
>
> On Wed, Dec 16, 2015 at 10:33 PM, Andi Vajda <os...@ovaltofu.org> wrote:
>
>>
>> On Wed, 16 Dec 2015, Dawid Weiss (JIRA) wrote:
>>
>>
>>> [
>>> https://issues.apache.org/jira/browse/LUCENE-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>> ]
>>>
>>> Dawid Weiss updated LUCENE-6933:
>>> --------------------------------
>>> Description:
>>> Goals:
>>> * selectively drop projects and core-irrelevant stuff:
>>> ** {{lucene/site}}
>>> ** {{lucene/nutch}}
>>> ** {{lucene/lucy}}
>>> ** {{lucene/tika}}
>>> ** {{lucene/hadoop}}
>>> ** {{lucene/mahout}}
>>> ** {{lucene/pylucene}}
>>>
>>
>> Does dropping lucene/pylucene mean it stays back in SVN (fine) or it
>> disappears (err, let's talk) ?
>>
>> Andi..
>>
>>
>> ** {{lucene/lucene.net}}
>>> ** {{lucene/old_versioned_docs}}
>>> ** {{lucene/openrelevance}}
>>> ** {{lucene/board-reports}}
>>> ** {{lucene/java/site}}
>>> ** {{lucene/java/nightly}}
>>> ** {{lucene/dev/nightly}}
>>> ** {{lucene/dev/lucene2878}}
>>> ** {{lucene/sandbox/luke}}
>>> ** {{lucene/solr/nightly}}
>>> * preserve the history of all changes to core sources (Solr and Lucene).
>>> ** {{lucene/java}}
>>> ** {{lucene/solr}}
>>> ** {{lucene/dev/trunk}}
>>> ** {{lucene/dev/branches/branch_3x}}
>>> ** {{lucene/dev/branches/branch_4x}}
>>> ** {{lucene/dev/branches/branch_5x}}
>>> * provide a way to link git commits and history with svn revisions (amend
>>> the log message).
>>> * annotate release tags
>>> * deal with large binary blobs (JARs): keep empty files instead for their
>>> historical reference only.
>>>
>>> Non goals:
>>> * no need to preserve "exact" merge history from SVN (see "impossible"
>>> below).
>>> * Ability to build ancient versions is not an issue.
>>>
>>> Impossible:
>>> * It is not possible to preserve SVN "merge history" because of the
>>> following reasons:
>>> ** Each commit in SVN operates on individual files. So one commit can
>>> "copy" (and record a merge) files from anywhere in the object tree, even
>>> modifying them along the way. There simply is no equivalent for this in git.
>>> ** There are historical commits in SVN that apply changes to multiple
>>> branches in one commit ({{r1569975}}).
>>> * Because exact merge tracking is impossible then what follows is that
>>> exact "linearized" history of a given file is also impossible to record.
>>> Let's say changes X, Y and Z have been applied to a branch of a file A and
>>> then merged back. In git, this would be reflected as a single commit
>>> flattening X, Y and Z (on the target branch) and three independent commits
>>> on the branch. The "copy-from" link from one branch to another cannot be
>>> represented because, as mentioned, merges are done on entire branches in
>>> git, not on individual files. Yes, there are commits in SVN history that
>>> have selective file merges (not entire branches).
>>>
>>>
>>> was:
>>> Goals:
>>> - selectively drop unnecessary stuff from history (cms/, javadocs/, JARs
>>> and perhaps other binaries),
>>> - *preserve* history of all core sources. So svn log IndexWriter has to
>>> go back all the way back to when Doug was young and pretty. Ooops, he's
>>> still pretty of course.
>>> - provide a way to link git history with svn revisions. I would, ideally,
>>> include a "imported from svn:rev XXX" in the commit log message.
>>> - annotate release tags and branches. I don't care much about interim
>>> branches -- they are not important to me (please speak up if you think
>>> otherwise).
>>>
>>> Non goals
>>> - no need to preserve "exact" history from SVN (the project may skip
>>> JARs, etc.). Ability to build ancient versions is not an issue.
>>>
>>>
>>> Create a (cleaned up) SVN history in git
>>>> ----------------------------------------
>>>>
>>>> Key: LUCENE-6933
>>>> URL: https://issues.apache.org/jira/browse/LUCENE-6933
>>>> Project: Lucene - Core
>>>> Issue Type: Task
>>>> Reporter: Dawid Weiss
>>>> Assignee: Dawid Weiss
>>>>
>>>> Goals:
>>>> * selectively drop projects and core-irrelevant stuff:
>>>> ** {{lucene/site}}
>>>> ** {{lucene/nutch}}
>>>> ** {{lucene/lucy}}
>>>> ** {{lucene/tika}}
>>>> ** {{lucene/hadoop}}
>>>> ** {{lucene/mahout}}
>>>> ** {{lucene/pylucene}}
>>>> ** {{lucene/lucene.net}}
>>>> ** {{lucene/old_versioned_docs}}
>>>> ** {{lucene/openrelevance}}
>>>> ** {{lucene/board-reports}}
>>>> ** {{lucene/java/site}}
>>>> ** {{lucene/java/nightly}}
>>>> ** {{lucene/dev/nightly}}
>>>> ** {{lucene/dev/lucene2878}}
>>>> ** {{lucene/sandbox/luke}}
>>>> ** {{lucene/solr/nightly}}
>>>> * preserve the history of all changes to core sources (Solr and Lucene).
>>>> ** {{lucene/java}}
>>>> ** {{lucene/solr}}
>>>> ** {{lucene/dev/trunk}}
>>>> ** {{lucene/dev/branches/branch_3x}}
>>>> ** {{lucene/dev/branches/branch_4x}}
>>>> ** {{lucene/dev/branches/branch_5x}}
>>>> * provide a way to link git commits and history with svn revisions
>>>> (amend the log message).
>>>> * annotate release tags
>>>> * deal with large binary blobs (JARs): keep empty files instead for
>>>> their historical reference only.
>>>> Non goals:
>>>> * no need to preserve "exact" merge history from SVN (see "impossible"
>>>> below).
>>>> * Ability to build ancient versions is not an issue.
>>>> Impossible:
>>>> * It is not possible to preserve SVN "merge history" because of the
>>>> following reasons:
>>>> ** Each commit in SVN operates on individual files. So one commit can
>>>> "copy" (and record a merge) files from anywhere in the object tree, even
>>>> modifying them along the way. There simply is no equivalent for this in git.
>>>> ** There are historical commits in SVN that apply changes to multiple
>>>> branches in one commit ({{r1569975}}).
>>>> * Because exact merge tracking is impossible then what follows is that
>>>> exact "linearized" history of a given file is also impossible to record.
>>>> Let's say changes X, Y and Z have been applied to a branch of a file A and
>>>> then merged back. In git, this would be reflected as a single commit
>>>> flattening X, Y and Z (on the target branch) and three independent commits
>>>> on the branch. The "copy-from" link from one branch to another cannot be
>>>> represented because, as mentioned, merges are done on entire branches in
>>>> git, not on individual files. Yes, there are commits in SVN history that
>>>> have selective file merges (not entire branches).
>>>>
>>>
>>>
>>>
>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.3.4#6332)
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [jira] [Updated] (LUCENE-6933) Create a (cleaned up) SVN history
in git
Posted by Dawid Weiss <da...@gmail.com>.
We can't touch Apache's SVN so it definitely stays! :)
This was also something that crossed my mind -- we effectively have
multiple separate projects in one git repo. While it's something SVN can
take, it's a more problematic issue with git. I don't know if one Apache
project can have multiple git repos, but I'd assume it'd be a natural way
out for pylucene? I can also include it in the git repo, of course, but I'd
opt for having a separate branch for it (one that is orphaned from actual
Lucene code).
Dawid
On Wed, Dec 16, 2015 at 10:33 PM, Andi Vajda <os...@ovaltofu.org> wrote:
>
> On Wed, 16 Dec 2015, Dawid Weiss (JIRA) wrote:
>
>
>> [
>> https://issues.apache.org/jira/browse/LUCENE-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Dawid Weiss updated LUCENE-6933:
>> --------------------------------
>> Description:
>> Goals:
>> * selectively drop projects and core-irrelevant stuff:
>> ** {{lucene/site}}
>> ** {{lucene/nutch}}
>> ** {{lucene/lucy}}
>> ** {{lucene/tika}}
>> ** {{lucene/hadoop}}
>> ** {{lucene/mahout}}
>> ** {{lucene/pylucene}}
>>
>
> Does dropping lucene/pylucene mean it stays back in SVN (fine) or it
> disappears (err, let's talk) ?
>
> Andi..
>
>
> ** {{lucene/lucene.net}}
>> ** {{lucene/old_versioned_docs}}
>> ** {{lucene/openrelevance}}
>> ** {{lucene/board-reports}}
>> ** {{lucene/java/site}}
>> ** {{lucene/java/nightly}}
>> ** {{lucene/dev/nightly}}
>> ** {{lucene/dev/lucene2878}}
>> ** {{lucene/sandbox/luke}}
>> ** {{lucene/solr/nightly}}
>> * preserve the history of all changes to core sources (Solr and Lucene).
>> ** {{lucene/java}}
>> ** {{lucene/solr}}
>> ** {{lucene/dev/trunk}}
>> ** {{lucene/dev/branches/branch_3x}}
>> ** {{lucene/dev/branches/branch_4x}}
>> ** {{lucene/dev/branches/branch_5x}}
>> * provide a way to link git commits and history with svn revisions (amend
>> the log message).
>> * annotate release tags
>> * deal with large binary blobs (JARs): keep empty files instead for their
>> historical reference only.
>>
>> Non goals:
>> * no need to preserve "exact" merge history from SVN (see "impossible"
>> below).
>> * Ability to build ancient versions is not an issue.
>>
>> Impossible:
>> * It is not possible to preserve SVN "merge history" because of the
>> following reasons:
>> ** Each commit in SVN operates on individual files. So one commit can
>> "copy" (and record a merge) files from anywhere in the object tree, even
>> modifying them along the way. There simply is no equivalent for this in git.
>> ** There are historical commits in SVN that apply changes to multiple
>> branches in one commit ({{r1569975}}).
>> * Because exact merge tracking is impossible then what follows is that
>> exact "linearized" history of a given file is also impossible to record.
>> Let's say changes X, Y and Z have been applied to a branch of a file A and
>> then merged back. In git, this would be reflected as a single commit
>> flattening X, Y and Z (on the target branch) and three independent commits
>> on the branch. The "copy-from" link from one branch to another cannot be
>> represented because, as mentioned, merges are done on entire branches in
>> git, not on individual files. Yes, there are commits in SVN history that
>> have selective file merges (not entire branches).
>>
>>
>> was:
>> Goals:
>> - selectively drop unnecessary stuff from history (cms/, javadocs/, JARs
>> and perhaps other binaries),
>> - *preserve* history of all core sources. So svn log IndexWriter has to
>> go back all the way back to when Doug was young and pretty. Ooops, he's
>> still pretty of course.
>> - provide a way to link git history with svn revisions. I would, ideally,
>> include a "imported from svn:rev XXX" in the commit log message.
>> - annotate release tags and branches. I don't care much about interim
>> branches -- they are not important to me (please speak up if you think
>> otherwise).
>>
>> Non goals
>> - no need to preserve "exact" history from SVN (the project may skip
>> JARs, etc.). Ability to build ancient versions is not an issue.
>>
>>
>> Create a (cleaned up) SVN history in git
>>> ----------------------------------------
>>>
>>> Key: LUCENE-6933
>>> URL: https://issues.apache.org/jira/browse/LUCENE-6933
>>> Project: Lucene - Core
>>> Issue Type: Task
>>> Reporter: Dawid Weiss
>>> Assignee: Dawid Weiss
>>>
>>> Goals:
>>> * selectively drop projects and core-irrelevant stuff:
>>> ** {{lucene/site}}
>>> ** {{lucene/nutch}}
>>> ** {{lucene/lucy}}
>>> ** {{lucene/tika}}
>>> ** {{lucene/hadoop}}
>>> ** {{lucene/mahout}}
>>> ** {{lucene/pylucene}}
>>> ** {{lucene/lucene.net}}
>>> ** {{lucene/old_versioned_docs}}
>>> ** {{lucene/openrelevance}}
>>> ** {{lucene/board-reports}}
>>> ** {{lucene/java/site}}
>>> ** {{lucene/java/nightly}}
>>> ** {{lucene/dev/nightly}}
>>> ** {{lucene/dev/lucene2878}}
>>> ** {{lucene/sandbox/luke}}
>>> ** {{lucene/solr/nightly}}
>>> * preserve the history of all changes to core sources (Solr and Lucene).
>>> ** {{lucene/java}}
>>> ** {{lucene/solr}}
>>> ** {{lucene/dev/trunk}}
>>> ** {{lucene/dev/branches/branch_3x}}
>>> ** {{lucene/dev/branches/branch_4x}}
>>> ** {{lucene/dev/branches/branch_5x}}
>>> * provide a way to link git commits and history with svn revisions
>>> (amend the log message).
>>> * annotate release tags
>>> * deal with large binary blobs (JARs): keep empty files instead for
>>> their historical reference only.
>>> Non goals:
>>> * no need to preserve "exact" merge history from SVN (see "impossible"
>>> below).
>>> * Ability to build ancient versions is not an issue.
>>> Impossible:
>>> * It is not possible to preserve SVN "merge history" because of the
>>> following reasons:
>>> ** Each commit in SVN operates on individual files. So one commit can
>>> "copy" (and record a merge) files from anywhere in the object tree, even
>>> modifying them along the way. There simply is no equivalent for this in git.
>>> ** There are historical commits in SVN that apply changes to multiple
>>> branches in one commit ({{r1569975}}).
>>> * Because exact merge tracking is impossible then what follows is that
>>> exact "linearized" history of a given file is also impossible to record.
>>> Let's say changes X, Y and Z have been applied to a branch of a file A and
>>> then merged back. In git, this would be reflected as a single commit
>>> flattening X, Y and Z (on the target branch) and three independent commits
>>> on the branch. The "copy-from" link from one branch to another cannot be
>>> represented because, as mentioned, merges are done on entire branches in
>>> git, not on individual files. Yes, there are commits in SVN history that
>>> have selective file merges (not entire branches).
>>>
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.4#6332)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: [jira] [Updated] (LUCENE-6933) Create a (cleaned up) SVN history
in git
Posted by Andi Vajda <os...@ovaltofu.org>.
On Wed, 16 Dec 2015, Dawid Weiss (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/LUCENE-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Dawid Weiss updated LUCENE-6933:
> --------------------------------
> Description:
> Goals:
> * selectively drop projects and core-irrelevant stuff:
> ** {{lucene/site}}
> ** {{lucene/nutch}}
> ** {{lucene/lucy}}
> ** {{lucene/tika}}
> ** {{lucene/hadoop}}
> ** {{lucene/mahout}}
> ** {{lucene/pylucene}}
Does dropping lucene/pylucene mean it stays back in SVN (fine) or
it disappears (err, let's talk) ?
Andi..
> ** {{lucene/lucene.net}}
> ** {{lucene/old_versioned_docs}}
> ** {{lucene/openrelevance}}
> ** {{lucene/board-reports}}
> ** {{lucene/java/site}}
> ** {{lucene/java/nightly}}
> ** {{lucene/dev/nightly}}
> ** {{lucene/dev/lucene2878}}
> ** {{lucene/sandbox/luke}}
> ** {{lucene/solr/nightly}}
> * preserve the history of all changes to core sources (Solr and Lucene).
> ** {{lucene/java}}
> ** {{lucene/solr}}
> ** {{lucene/dev/trunk}}
> ** {{lucene/dev/branches/branch_3x}}
> ** {{lucene/dev/branches/branch_4x}}
> ** {{lucene/dev/branches/branch_5x}}
> * provide a way to link git commits and history with svn revisions (amend the log message).
> * annotate release tags
> * deal with large binary blobs (JARs): keep empty files instead for their historical reference only.
>
> Non goals:
> * no need to preserve "exact" merge history from SVN (see "impossible" below).
> * Ability to build ancient versions is not an issue.
>
> Impossible:
> * It is not possible to preserve SVN "merge history" because of the following reasons:
> ** Each commit in SVN operates on individual files. So one commit can "copy" (and record a merge) files from anywhere in the object tree, even modifying them along the way. There simply is no equivalent for this in git.
> ** There are historical commits in SVN that apply changes to multiple branches in one commit ({{r1569975}}).
> * Because exact merge tracking is impossible then what follows is that exact "linearized" history of a given file is also impossible to record. Let's say changes X, Y and Z have been applied to a branch of a file A and then merged back. In git, this would be reflected as a single commit flattening X, Y and Z (on the target branch) and three independent commits on the branch. The "copy-from" link from one branch to another cannot be represented because, as mentioned, merges are done on entire branches in git, not on individual files. Yes, there are commits in SVN history that have selective file merges (not entire branches).
>
>
> was:
> Goals:
> - selectively drop unnecessary stuff from history (cms/, javadocs/, JARs and perhaps other binaries),
> - *preserve* history of all core sources. So svn log IndexWriter has to go back all the way back to when Doug was young and pretty. Ooops, he's still pretty of course.
> - provide a way to link git history with svn revisions. I would, ideally, include a "imported from svn:rev XXX" in the commit log message.
> - annotate release tags and branches. I don't care much about interim branches -- they are not important to me (please speak up if you think otherwise).
>
> Non goals
> - no need to preserve "exact" history from SVN (the project may skip JARs, etc.). Ability to build ancient versions is not an issue.
>
>
>> Create a (cleaned up) SVN history in git
>> ----------------------------------------
>>
>> Key: LUCENE-6933
>> URL: https://issues.apache.org/jira/browse/LUCENE-6933
>> Project: Lucene - Core
>> Issue Type: Task
>> Reporter: Dawid Weiss
>> Assignee: Dawid Weiss
>>
>> Goals:
>> * selectively drop projects and core-irrelevant stuff:
>> ** {{lucene/site}}
>> ** {{lucene/nutch}}
>> ** {{lucene/lucy}}
>> ** {{lucene/tika}}
>> ** {{lucene/hadoop}}
>> ** {{lucene/mahout}}
>> ** {{lucene/pylucene}}
>> ** {{lucene/lucene.net}}
>> ** {{lucene/old_versioned_docs}}
>> ** {{lucene/openrelevance}}
>> ** {{lucene/board-reports}}
>> ** {{lucene/java/site}}
>> ** {{lucene/java/nightly}}
>> ** {{lucene/dev/nightly}}
>> ** {{lucene/dev/lucene2878}}
>> ** {{lucene/sandbox/luke}}
>> ** {{lucene/solr/nightly}}
>> * preserve the history of all changes to core sources (Solr and Lucene).
>> ** {{lucene/java}}
>> ** {{lucene/solr}}
>> ** {{lucene/dev/trunk}}
>> ** {{lucene/dev/branches/branch_3x}}
>> ** {{lucene/dev/branches/branch_4x}}
>> ** {{lucene/dev/branches/branch_5x}}
>> * provide a way to link git commits and history with svn revisions (amend the log message).
>> * annotate release tags
>> * deal with large binary blobs (JARs): keep empty files instead for their historical reference only.
>> Non goals:
>> * no need to preserve "exact" merge history from SVN (see "impossible" below).
>> * Ability to build ancient versions is not an issue.
>> Impossible:
>> * It is not possible to preserve SVN "merge history" because of the following reasons:
>> ** Each commit in SVN operates on individual files. So one commit can "copy" (and record a merge) files from anywhere in the object tree, even modifying them along the way. There simply is no equivalent for this in git.
>> ** There are historical commits in SVN that apply changes to multiple branches in one commit ({{r1569975}}).
>> * Because exact merge tracking is impossible then what follows is that exact "linearized" history of a given file is also impossible to record. Let's say changes X, Y and Z have been applied to a branch of a file A and then merged back. In git, this would be reflected as a single commit flattening X, Y and Z (on the target branch) and three independent commits on the branch. The "copy-from" link from one branch to another cannot be represented because, as mentioned, merges are done on entire branches in git, not on individual files. Yes, there are commits in SVN history that have selective file merges (not entire branches).
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org