I successfully executed subgit import on large old repository.
Later i discovered, that there were two directories for tags: default tags and tag.
I tried to edit subgit config file according to advices in Does subgit support multiple 'branches' directories?
Currently i have tags configured the following way:'
tags = tags/*:refs/tags/*
tags = tag/*:refs/tags/tag/*
But now when i try to execute import command again, Subgit does nothing, like everything seems to be already up to date. What i did wrong or i need to run subgit import from scratch?
Indeed, you have to start importing from scratch. You can run
$ subgit configure --svn-url SVN_URL repo.git
Then edit repo.git/subgit/config to specify
tags = tags/*:refs/tags/*
tags = tag/*:refs/tags/tag/*
Then
$ subgit install repo.git
and finally
$ subgit uninstall repo.git
to stop continuous synchronization. You can also use "subgit import" command as a shortcut for "subgit install" + "subgit uninstall".
As a bonus you'll have all SVN revision numbers saved in refs/svn/map reference. To see revision numbers in "git log" output you can setup you Git clients as it is recommended in SubGit book or run the following command on the server:
$ git update-ref refs/notes/commits refs/svn/map
Related
I tried to import the biopython package in Spyder and got the error message:
ModuleNotFoundError: No module named 'biopython'
although biopython is installed.
I also checked the PYTHONPATH: there is a path set into the directory where the packages are stored.
Can somebody help? Did I miss something? Thanks for your help!
If you're using Anaconda, it's best to install all the packages you want from Anaconda if possible. You can check if a package is available with (e.g.):
conda search biopython
When I try that command it shows that biopython is available, so assuming you have access to the standard conda channels you should be able to get it this way.
Assuming you haven't already created a conda environment to work with, start by creating a new one with the packages you want to use:
conda create -n myenvname spyder biopython
where myenvname is the name you want to give the environment - call it whatever you like. If you want to use other packages as well, add their names to the end of this command. Then once the env is completed, activate it:
activate myenvname
or if this doesn't work, on Mac or Linux:
source activate myenvname
and start Spyder in this environment:
spyder
Each time you want to use this environment in future you will need to activate it first. You may also be able to do some of these tasks through the Anaconda Navigator or via Start menu shortcuts but the command line version will always work.
If there's a package you want that isn't available from conda but is available via pip, just use the pip command after creating and activating the environment.
If you are using Anaconda, a solution could be
conda install -c main biopython
following https://anaconda.org/main/biopython.
The official repository page helped me when I got your error message because numpy was not in place.
I'm having trouble setting up Go App engine on osX. Should the google-cloud-sdk path be in GOROOT or GOPATH?
I put the google-cloud-sdk in /usr/local
It looks like there is source code in: goroot/
/usr/local/google-cloud-sdk/platform/google_appengine/goroot/
go env
GOPATH="/usr/local/google-cloud-sdk/platform/google_appengine/goroot"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
$ go get
package google.golang.org/appengine: cannot download, /usr/local/google-cloud-sdk/platform/google_appengine/goroot is a GOROOT, not a GOPATH. For more details see: 'go help gopath'
package google.golang.org/appengine/datastore: cannot download, /usr/local/google-cloud-sdk/platform/google_appengine/goroot is a GOROOT, not a GOPATH. For more details see: 'go help gopath'
When I attempted to change the PATH to include /src:
GOPATH="/usr/local/google-cloud-sdk/platform/google_appengine/goroot/src"
$ go get
package google.golang.org/appengine: mkdir /usr/local/google-cloud-sdk/platform/google_appengine/goroot/src/src: permission denied
package google.golang.org/appengine/datastore: cannot find package "google.golang.org/appengine/datastore" in any of:
/usr/local/go/src/google.golang.org/appengine/datastore (from $GOROOT)
/usr/local/google-cloud-sdk/platform/google_appengine/goroot/src/src/google.golang.org/appengine/datastore (from $GOPATH)
I appended the path to google-cloud-sdk to GOROOT:
export GOROOT="/usr/local/go/:/usr/local/google-cloud-sdk/platform/google_appengine/goroot"
GO doesn't seem to like multiple paths in GOROOT:
$ go get
go: cannot find GOROOT directory: /usr/local/go/:/usr/local/google-cloud-sdk/platform/google_appengine/goroot
I did run the ./install.sh script after I copied the source to /usr/local
The additional PATH's added did not fix the errors I was having.
I saw this answer: Test cases for go and appengine
But it's from 5 years ago and it seems clunky/hacky. It would seem in 5 years there would be a more elegant solution that copying individual directories and creating symlinks.
EDIT **********************
mv /usr/local/google-cloud-sdk/ ~/go/ then deleted GOPATH and GOROOT from .bash_profile
I then ran ./install.sh
I attempted to run 'go get':
$ go get
go install: no install location for directory /Users/Bryan/work/gocode/skincarereview outside GOPATH
Since that failed, I added the path to the working directory of code AND appended the path to google-cloud-sdk to PATH:
export GOPATH = "/Users/Bryan/work/gocode/skincarereview"
export PATH=$HOME/google-cloud-sdk:$PATH
go get get failed with the same message:
$ go get
go install: no install location for directory /Users/Bryan/work/gocode/skincarereview outside GOPATH
For more details see: 'go help gopath'
It goes in neither $GOROOT or $GOPATH. Just unpack it to your $HOME directory and run the installer. If necessary, add it to your $PATH by adding this line to your .bash_profile.
export PATH=$HOME/google-cloud-sdk:$PATH
Make sure you grab the golang SDK as well with gcloud components install app-engine-go https://cloud.google.com/appengine/docs/standard/go/download
DO NOT change your path to include the src dir in google-cloud-sdk/platform/google_appengine/goroot/src. That will break things. You leave your $GOPATH to be your normal installation. Using the App Engine SDK for Go automatically uses the sources in that dir without any manipulation.
Also, you should NEVER MANUALLY change $GOROOT unless you plan on compiling a new Go version from source (as in a new version of the language). It will automatically set the proper $GOROOT for you. https://dave.cheney.net/2013/06/14/you-dont-need-to-set-goroot-really
If your install is messed up beyond reason (happened to me once), just remove the cloud SDK and any references to it in your $PATH. Also completely uninstall the regular Go installation. Then start from scratch. Install Go, unpack google-cloud-sdk, run installer (add to $PATH if needed), gcloud components install app-engine-go. Voila.
When developing for App Engine, your go sources go into your REGULAR $GOPATH. They DO NOT go in google-cloud-sdk/... anywhere. To run the dev_appserver locally, run dev_appserver.py [path-to-source] where the given path contains your code and the app.yaml. I usually cd in to my project path (e.g. cd $HOME/go/src/myproject) and run with dev_appserver.py ./. https://cloud.google.com/appengine/docs/standard/go/tools/using-local-server
Deployment is covered here. https://cloud.google.com/appengine/docs/standard/go/tools/uploadinganapp
EDIT: Folder structure.
$GOPATH = $HOME/go
Location for google-cloud-sdk folder
I'm trying to do an import using subgit. Just a one-time migration. My SVN structure contains:
branches
branch1
features
branch2
hotfixes
branch3
I'd like to convert all three to branches in git. I've tried:
proj=myproject; subgit import --svn-url <correctPath>/$proj --authors-file
~/authors --branches branches --branches branches/features
--branches hotfixes --tags tags $i
This seems to just use "hotfixes" as the only place to import from. (I'm using SubGit version 2.0.2 ('Patrick') build #2731.) I also tried using:
--branches "branches;branches/features;hotfixes"
But that completely failed (it was probably looking for a directory with semi-colons in it).
Any suggestion for the one-time import?
(Note, I saw this related question.)
You can use a combination of 'configure' + 'install' + 'uninstall' commands. I suppose, your repository has the following structure:
$ svn ls --depth infinity <SVN_URL>
branches/
branches/branch1/
branches/branch2/
branches/features/
branches/features/feature1/
branches/features/feature2/
hotfixes/
hotfixes/hotfix1/
hotfixes/hotfix2/
tags/
tags/tag1/
tags/tag2/
trunk/
Then do the following. Run 'configure' command:
$ subgit configure --svn-url <SVN_URL> repo
Edit repo/subgit/config file to this repository structure (or you can invent your own refs/heads/ namespaces, the only requirement is: the shouldn't be the same for different kinds of branches; if you need one-time import and everything under refs/heads/*, you can rename them later with a script):
trunk = trunk:refs/heads/master
branches = branches/*:refs/heads/*
branches = branches/features/*:refs/heads/features/*
branches = hotfixes/*:refs/heads/hotfixes/*
tags = tags/*:refs/tags/*
shelves = shelves/*:refs/shelves/*
Run 'install' command:
$ subgit install repo
Then if you run "git branch -a" from "repo" directory, you'll see something like that:
$ git branch -a
branch1
branch2
features/feature1
features/feature2
hotfixes/hotfix1
hotfixes/hotfix2
* master
Optionally you can run 'uninstall' command to disable synchronization temporary or forever (--purge option)
$ subgit uninstall [--purge] repo
Being windows users, we created one svn repo with a hierarchy of folders. The bottom nodes contain the svn standard layout:
ProjectA/
ApplicationOne/
ModuleX/
trunk/
branches/
tags/
ApplicationTwo/
ModuleY/
trunk/
branches/
tags/
... and so on ad infinitum. The repo now contains around 100+ real svn projects with the trunk/branches/tags structure, but almost none of them at the top level.
How would I configure subgit to handle this?
SubGit can work in two different modes: local mirror mode and remote mirror mode. Below you can find a general overview of these modes and some recommendations for your particular case.
Local Mirror Mode
In this mode both Subversion and Git repositories reside on the same host, so SubGit has local access to both SVN and Git sides.
Below I've provided basic instructions. Please find detailed documentation and common pitfalls in SubGit 'Local Mode' Book.
Configuration
subgit configure <SVN_REPO>
SubGit version <VERSION> build #<BUILD_NUMBER>
Detecting paths eligible for translation... done.
Subversion to Git mapping has been configured:
/ProjectA/ApplicationOne/ModuleX : <SVN_REPO>/git/ProjectA/ApplicationOne/ModuleX.git
/ProjectA/ApplicationTwo/ModuleY : <SVN_REPO>/git/ProjectA/ApplicationTwo/ModuleY.git
...
CONFIGURATION SUCCESSFUL
...
This command tries to auto-detect repository layout and generate configuration file at <SVN_REPO>/conf/subgit.conf. It may take a while in case of big Subversion repository like yours.
Please make sure that auto-generated configuration file looks as follows, adjust it if necessary:
...
[git "ProjectA/ApplicationOne/ModuleX"]
translationRoot = /ProjectA/ApplicationOne/ModuleX
repository = git//ProjectA/ApplicationOne/ModuleX.git
pathEncoding = UTF-8
trunk = trunk:refs/heads/master
branches = branches/*:refs/heads/*
shelves = shelves/*:refs/shelves/*
tags = tags/*:refs/tags/*
...
Authors mapping
At this stage you have to create /conf/authors.txt file that maps existing SVN usernames to Git authors. Please refer to documentation for more details.
Installation
Finally you have to import your Subversion repository to Git and enable synchronization by running subgit install command:
subgit install repo
SubGit version <VERSION> build #<BUILD_NUMBER>
Subversion to Git mapping has been found:
/ProjectA/ApplicationOne/ModuleX : <SVN_REPO>/git/ProjectA/ApplicationOne/ModuleX.git
/ProjectA/ApplicationTwo/ModuleY : <SVN_REPO>/git/ProjectA/ApplicationTwo/ModuleY.git
...
Processing '/ProjectA/ApplicationOne/ModuleX'
Translating Subversion revisions to Git commits...
Processing '/ProjectA/ApplicationTwo/ModuleY'
Translating Subversion revisions to Git commits...
...
Subversion revisions translated: <REVISIONS_NUMBER>.
Total time: <TIME_SPENT> seconds.
INSTALLATION SUCCESSFUL
Git Server
When the installation is over and synchronization between Subversion and Git repositories is enabled, you can setup some Git server (or reuse existing Apache HTTP server). Please refer to documentation on that and see a couple of posts on this topic in our blog:
VisualSVN Server and SubGit
Gitolite and SubGit
Remote Mirror Mode
When using this mode one has to install SubGit into Git repository only and keep this repository synchronized with remote Subversion server hosted on a different machine.
Below you can find some basic instructions. Please refer to SubGit 'Remote Mode' Book for more details.
Configuration
In remote mirror mode SubGit does not try to auto-detect repository layout, so you have to run subgit configure --svn-url <SVN_URL> command for every module within Subversion repository:
subgit configure --svn-url <SVN_ROOT_URL>/ProjectA/ApplicationOne/ModuleX <GIT_ROOT_DIR>/ProjectA/ApplicationOne/ModuleX.git
SubGit version <VERSION> build #<BUILD_NUMBER>
Configuring writable Git mirror of remote Subversion repository:
Subversion repository URL : <SVN_ROOT_URL>/ProjectA/ApplicationOne/ModuleX
Git repository location : <GIT_ROOT_DIR>/ProjectA/ApplicationOne/ModuleX.git
CONFIGURATION SUCCESSFUL
...
As result SubGit generates configuration file <GIT_REPO>/subgit/config for every Git repository. For your case this configuration file should look as follows:
...
[svn]
url = <SVN_ROOT_URL>/ProjectA/ApplicationOne/ModuleX
trunk = trunk:refs/heads/master
branches = branches/*:refs/heads/*
tags = tags/*:refs/tags/*
shelves = shelves/*:refs/shelves/*
fetchInterval = 60
connectTimeout = 30
readTimeout = 60
keepGitCommitTime = false
auth = default
[auth "default"]
passwords = subgit/passwd
useDefaultSubversionConfigurationDirectory = false
subversionConfigurationDirectory = <SVN_CONFIG_DIR>
...
Authors mapping
At this stage you have to create /subgit/authors.txt file that maps existing SVN usernames to Git authors. Please refer to documentation for more details.
SVN credentials
In case you're not using file:// protocol you have to provide necessary credentials, so SubGit is able to authenticate against Subversion server. For more information on that please read corresponding chapter in SubGit Book.
We also recommend enabling pre-revprop-change hook on Subversion side which makes further installation and maintenance a bit easier, see SubGit Book.
Installation
Finally you have to import your Subversion repository to Git and enable synchronization by running subgit install command:
subgit install git
SubGit version <VERSION> build #<BUILD_NUMBER>
Translating Subversion revisions to Git commits...
Subversion revisions translated: <REVISIONS_NUMBER>.
Total time: <TIME_SPENT> seconds.
INSTALLATION SUCCESSFUL
This command also launches background process that polls SVN server and fetches new revisions when they appear there. Basically, that means that SubGit uses dedicated process for every Git repository. Sometimes it makes sense to avoid running such processes and use some job scheduler instead.
Git server
Those links I've provided above are relevant for remote mode as well.
However, if you're going to use Atlassian Stash for Git hosting, you can use SVN Mirror Plugin which is based on SubGit engine and provides some better experience with regards to UI and maintenance.
We have the following guideline which is based on our experience:
In case of many independent Subversion repositories, it's better to use SubGit in local mirror mode as it doesn't require SVN polling and maintaining additional process(es) for that.
In case of one giant Subversion repository with many modules, it's better to use remote mirror mode with file:// protocol and also adjust basic setup slightly.
It definitely doesn't make sense to run 100+ background processes in your case, instead we recommend installing additional post-commit SVN hook that checks what particular modules were modified by a given revision and then triggers synchronization for corresponding Git repositories.
If you have any other questions, feel free to ask us here at Stack Overflow, at our issue tracker or contact us via email: support#subgit.com.
The mode files for Coda.app (for syntax highlighting etc etc) hosted at rolling address come with these instructions. I enter the line in terminal and hit return but nothing seemed to get created. I was logged into github in Safari with my account. I haven't used github so I don't know much about it other that it's a web based version control system that all the cool kids use.
https://github.com/bobthecow/coda-modes#readme
readme:
Syntax modes for Coda and SubEthaEdit
A selection of syntax modes for for Coda (and SubEthaEdit) curated by bobthecow.
Installation
If you already have a folder at ~/Library/Application Support/Coda/Modes move it (or remove it if it's empty).
Check out this repository:
cd ~/Library/Application\ Support/Coda git clone --recursive git://github.com/bobthecow/coda-modes.git Modes
If you have additional syntax modes in your old Modes folder, copy them into this folder.
Restart Coda.
Just to be sure, those are supposed to be two command lines here:
cd ~/Library/Application\ Support/Coda
git clone --recursive git://github.com/bobthecow/coda-modes.git Modes
This should create a "Modes" directory within "~/Library/Application\ Support/Coda".
If the git address doesn't work, try the htts one:
git clone --recursive https://github.com/bobthecow/coda-modes.git Modes
Note that a git clone --recursive initializes all submodules within, using their default settings. This is equivalent to running git submodule update --init --recursive immediately after the clone is finished.