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 <o...@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-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
