Skip to content

[Bioc-devel] Reset SVN repo to earlier state

3 messages · Lukas Weber, Martin Morgan

#
Hi,

Is there any way to reset the devel branch of a package SVN repo / git
mirror to an earlier state, or simply to delete the devel branch and start
again from a copy of release-3.4?

I made a mess in my SVN repo by trying to combine my previous git history
(prior to Bioconductor acceptance) together with new commits from SVN in a
single git branch. Unfortunately, at one point I dcommitted all the old git
commits on top of the existing commits in the SVN repo, which was not a
very good idea. Now the SVN repo appears to be stuck (possibly due to
changes in the version number in DESCRIPTION).

Ideally, I would like to just delete the whole devel branch and start again
from a fresh copy of release-3.4, but I'm not sure if this can be done
without manual intervention. Alternatively, if there is a way to reset to
this earlier git-svn-id, that could also work:
https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/regsplice at 122712.
All my work since then is backed up elsewhere, so I can recover everything
from there.

A link to the package is here:
http://bioconductor.org/packages/release/bioc/html/regsplice.html

Thanks and sorry for the inconvenience,
Lukas
#
On 11/16/2016 04:56 AM, Lukas Weber wrote:
You're making changes to the 'devel' branch, so the relevant build report is

   http://bioconductor.org/checkResults/3.5/bioc-LATEST/regsplice/

and the relevant landing page is

   http://bioconductor.org/packages/3.5/bioc/html/regsplice.html

I mention this because you say the 'SVN repo appears stuck' but it 
actually seems like, modulo the nightly builds, the package is 
up-to-date with svn. Also the last svn revision was

r124171 | l.weber | 2016-11-15 19:21:04 -0500 (Tue, 15 Nov 2016) | 3 lines

so quite current. The Bioconductor-mirror choked on your multiple svn 
commits in short succession; I have updated the mirror so it is in sync 
again.

If you do want to 'start again' in svn, it is straight-forward to 
'reverse merge' from a current to a historical revision. I did

   cd regsplice
   svn log|less

and then searched until I found the version bump that started the devel 
branch, r122712. I then did the reverse merge

   svn merge -rHEAD:122712 .

and if that is where you want to start from, I'd bump the version to be 
1.1.z, where z is larger than any z you've used for your package so far 
(looks like the current head is 1.1.5, so that would be 1.1.6) and then

   svn ci

I don't really know how you would coordinate this in git and svn; I 
think an easier strategy would be to get your git repo into the 
condition you want, and then dcommit to svn. Personally, I find the git 
/ svn interface so challenging that I do not use git for packages whose 
cannonical repository is svn.

Martin
This email message may contain legally privileged and/or...{{dropped:2}}
#
Thank you for the detailed reply. I think I have managed to fix it now.

Syncing the Bioconductor-mirror properly was actually the only major thing
required. For my local Git repository, I cloned a fresh copy (including
pre-Bioconductor history) from GitHub, created a new master branch from the
pre-Bioconductor history, and used 'git cherry-pick' to add all the new
changes since then into this new master branch. The final state of this new
master branch was now identical to the Bioconductor-mirror. Then I used
'git push --force' to put it back in my GitHub repo.

To check things, I added a version bump to the master branch, 'git
cherry-picked' it over to 'devel' branch, and 'git svn dcommitted' it.
Everything seems to be fine now; although there is a fairly long messy
history (~100 commits) in the SVN repo and Bioconductor-mirror (but I don't
think this matters). Reversing commits in SVN wasn't necessary in the end.

I think my main problem was trying to use 'git merge' instead of 'git
cherry-pick'. As long as I only use 'git cherry-pick' to move changes
between 'master' and 'devel', I can continue to use my original Git/GitHub
repo as my main development repo. I was also confused because this means
the SHA hashes are different between 'master' and 'devel', but again this
doesn't seem to matter. Earlier on I also tried some things with 'git
graft' and 'git replace', but this isn't necessary now.

Best regards,
Lukas


Lukas Weber
PhD student
University of Zurich, Switzerland


On Wed, Nov 16, 2016 at 11:51 AM, Martin Morgan <
martin.morgan at roswellpark.org> wrote: