Skip to content

[Bioc-devel] Bioconductor git-svn bridge is available

11 messages · Moritz Gerstung, Henrik Bengtsson, Hector Corrada Bravo +3 more

#
Hi all

Following Kasper's idea from a couple of months ago: Would it be possible to have the git-svn bridge synchronise a branch other than master? 

If so, one could use the git subtree command,

git subtree split -P minfi -b biocsvn

to create a branch 'biocsvn' only containing minfi directory [package]. This branch would then be synchronised over the git-svn bridge. Changes in the biocsvn branch can be merged back into the master branch and the correct directory with 

git subtree merge -P minfi biocsvn

I would also fancy a directory structure as Kasper suggested, where the actual R package is a subdirectory. This would allow for placing extra files such as README.md or Makefile into the root directory and other project related data which shouldn't go into the package, but may be useful, in other directories. As a side effect one can also screw up the git master branch without breaking the devel repository.

I'm not a git guru, so maybe I'm missing something here, but it seems feasible.

Cheers,

Moritz

PS. Resent as it bounced from list before.
On 21 Feb 2014, at 17:00, Kasper Daniel Hansen <kasperdanielhansen at gmail.com> wrote:

            

  
    
#
Hi Moritz,

----- Original Message -----
It does seem doable. It may take a while before I have time to implement this.
Thanks.
Dan
#
On Mon, May 12, 2014 at 1:32 AM, Moritz Gerstung <mg14 at sanger.ac.uk> wrote:
Just a FYI: Using .Rbuildignore you can still add Makefile and other
files to the repository that won't go into the package
build/install/check/distro/....  This works regardless of Subversion
of Git.

/Henrik
#
----- Original Message -----
Right. But if you wanted to structure your repo like this:

- README
- package/
    DESCRIPTION
    etc
- otherstuff/

where the actual R package is in the 'package' directory, then .Rbuildignore would not help.

This (I think) is what the original request was about.

Dan
9 days later
#
Hi Kasper,

----- Original Message -----
What is the error?

Also, what is your OS (+ version + distro) and browser ( + version)? I have a report that there are are problems creating bridges on Linux using firefox and chrome but that it worked for this user with firefox on windows (and for me on Mac with several browsers). I'll do some testing.


If there is a javascript console available, can you see if there is an error there? If not, no worries, just let me know what config you're using.

Dan
#
----- Original Message -----
The issue has been fixed and your bridge has been created. Thanks for the report.
Dan
1 day later
#
I?m also having issues with my bridges. It seems that they always ?die" after the initial sync (which for me is always a Git win). After awhile when I commit again to GitHub, nothing happens on the SVN, and I end up deleting the bridges and re-creating them. This always does the trick, but when I commit the next time, it?s the same thing again.

I thought the problem was maybe with the webhook, so I went to double check it. I noticed that GitHub has probably updated these settings, since in the bridge documentation it says:
But it looks like nowadays the setting is called ?Content type? and options are ?application/json? and ?application/x-www-form-urlencoded? (which I have selected).

Otherwise everything looks to be ok (?Just the push event?, ?Active?, and the new option ?Secret? is empty), and under ?Recent Deliveries? I do see that the hook has indeed been triggered by my commits. So, I guess there must be something wrong with the bridge itself. Both my repositories (QDNAseq and QDNAseq-release) are organization ones, if that makes a difference. I don?t really know what else I could do to debug this. Maybe there could be some kind of logging that was visible to the bridge owners.

Ilari
On 22.5.2014, at 3.59, Dan Tenenbaum <dtenenba at fhcrc.org> wrote:

            
#
Hi Ilari,

----- Original Message -----
I apologize for the problems. Github keeps changing the format of the push hooks they send, and they don't seem to document these in a consistent way. However, I've made my code more robust in that it recognizes the variations that I have seen so far. 

So, if you go to the settings page for your repos (the page you were on before) and go down to "Recent deliveries", and expand (click on "...") the deliveries corresponding to your recent git commits, then click "Redeliver", this will send the message to the bridge that there is a new commit, and this time the bridge should handle it properly.

I'll update the documentation with the changed verbiage on that page.

Thanks,
Dan