Thank you Jim for your reply. SubGit does highlight its ability to handle non-linear histories as compared to GitSVN -- http://www.subgit.com/documentation/gitsvn.html.
I will keep looking as well. Thanks. On Wed, Jul 15, 2015 at 9:03 AM Jim Hester <james.f.hes...@gmail.com> wrote: > Sid, > > I think you have characterized the main issue well, a number of people > have run into issues stemming from the same problem. ( > https://stat.ethz.ch/pipermail/bioc-devel/2015-June/007726.html, > https://stat.ethz.ch/pipermail/bioc-devel/2015-June/007730.html and a > number of off-list queries). > > As you mentioned the problems stem from the fact the SVN repositories has > only truncated history compared to the git repositories. Because git-svn > only handles completely linear histories even if you merge the two > histories locally you can still run into problems when running git svn > dcommit. > > I agree syncing the SVN history with the original GitHub history should in > theory fix this problem, however because you cannot rewrite history with > SVN I am not positive it is actually possible to accomplish. > > I will investigate that stackoverflow answer to see if there is any > techniques we could apply here, thank you for the link I had not come > across that previously. > > I am also separately investigating a SubGit <http://www.subgit.com/> > solution that I believe will address this issue and also allow users to > interact with Bioconductor repositories exactly how they would with any > other git remote. > > Thank you reaching out, this is definitely a pain point I am aware of and > trying to actively address. The current solution is IMHO less than ideal. I > would be happy to talk at Bioc2015 next week if you want to discuss in > person. > > Jim > > On Tue, Jul 14, 2015 at 4:34 PM, Siddhartha Bagaria <s...@google.com> > wrote: > > [cc]: bioc-devel for discussion with wider community. >> >> Hello Jim! >> >> This is related to using the new git mirror setup with pre-existing >> github repos (not forks of the mirror). >> >> I tried following the thread on >> https://stat.ethz.ch/pipermail/bioc-devel/2015-June/007725.html but it >> looks like the problem was not clearly reproduced, and a solution was not >> reached. I will briefly describe the problem here but am inclined to >> discuss possible solutions further in person during the upcoming conference >> if you will be there. >> >> The problem with an already existing github repo in the new setup is that >> the master branch of that repo will have its own commit history, which will >> be different from the svn commit history (no common ancestor). As a result, >> merging the entire master branch into the newly created devel branch will >> try to merge all the commits from master since the beginning. Because there >> is no common ancestor, all the new edits will appear as merge-conflicts. >> One can manually resolve these conflicts but the process is cumbersome and >> error-prone. >> >> One way of skipping to manually resolve all the conflicts is merging the >> commits from devel into master first with strategy "ours", so that master >> gets the commit logs from devel but the content in master is unchanged (to >> avoid addressing conflicts). After this, a merge back into devel will work >> without conflicts. However, there is a problem with both these merge >> approaches. >> >> After a resolved merge (through manual resolution of conflicts, or >> through pre-merging histories), the commit histories between devel and >> master branches will be in sync, but the commit history in devel will now >> have extra entries from master interleaved with its previously existing >> entries. This would mean that now the devel branch and the svn repo do not >> have a common history. 'git svn' will get confused by these interleaved >> commits and will complain "Unable to determine upstream SVN information >> from HEAD history". So a merge does not work with this setup. >> >> The easiest solution so far is to cherry-pick the new commits from master >> and only merge those with the devel branch, so that svn and git continue to >> share a common history up until the cherry-picks. While this works >> smoothly, this is error-prone again as a commit can be missed when manually >> cherry-picking. >> >> It seems like one solution would be a one-time ability to sync the commit >> history of SVN repo with the commit history of the original github repo. >> This way, all three repos will have common ancestors. Other solutions which >> I have not studied in depth include: >> http://stackoverflow.com/questions/3864934/how-do-i-re-integrate-a-svn-and-git-repository-without-a-common-history >> >> Let me know if you would like a reproducible example. I am happy to >> discuss more. >> >> Cheers! >> >> Sid >> > > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
