Home

This is how I setup ArtiSynth for development so that I can use Git on my end to communicate with the the SVN server that ArtiSynth is being hosted on.
First, checkout artisynth_core using git-svn commands. Remember not to checkout trunk, but use the --stdlayout option so that branches and tags are incorporated correctly:

$ cd ~/<Documents/>workspace/
$ git svn clone --stdlayout --prefix=origin/ https://svn.artisynth.org/svn/artisynth_core
$ cd artisynth_core
$ unzip eclipseSettings.zip
$ cd ..

Remember to unzip eclipseSettings.zip BEFORE adding as an Eclipse project!
This should now be repeated for artisynth_models and artisynth_projects.

The general model I use for working on ArtiSynth is I think pretty typical for git workflow; that is, allow master to be a ``clean'' copy of origin/master, and to do my work in local feature branches. I usually just have a general ``working'' branch that I use, unless I have a well-defined new feature I'm working on, in which case it will have its own feature branch. Importing changes is pretty straightforward with the git svn rebase command. REMEMBER TO DO THIS ON MASTER!
If you are on working and have some uncommitted changes.
$ git stash
$ git checkout master
$ git svn rebase
$ git checkout <branch_name, eg working>
$ git merge master
Repeat cherry-pick for all applicable commits...
$ git cherry-pick <commit-ref-id>
$ git cherry-pick ...
Ensure everything at least compiles, now that we're merged onto master
$ make clean; make
$ make test;
Now you can finally commit to svn repo
$ git svn dcommit
$ git svn checkout <branch_name, eg working>
$ git svn rebase # any commits that weren't cherry-picked are now on new master
$ git stash pop

I find that using git-merge is better than using git-rebase to merge changes into my working branch because if I have a separate git server (ie my router at home) for keeping backups, git-rebase will rewrite git history and git push will complain unless git push -f is used. (I have a separate git server so that I can transfer code between laptop for development and desktop for running long simulations).

These days I have some commits that should not go onto main repo, but stay local to my machine. It's easiest to maintain these machine-specific settings by saving them as a commit, and leaving that commit out of the master branch. We use cherry-pick for work that needs to go into main repo, and a subsequent rebase will then merge the machine-specific work onto the new master branch. This is a really nice workflow, where diverging branches keep their correct meaning, and everything becomes linear again after <master> svn-rebase; <master> svn-dcommit; <working> svn-rebase;

Committing changes to SVN is also quite easy, by using the git svn dcommit command.
First, checkout master and update it using the git svn rebase as above.
Second, merge the feature branch (ie working or new-amazing-feature) into master.
Third, use git svn dcommit to push the changes upstream. I haven't run into any issues yet if I do everything in this order.
Finally, checkout the branch and merge the ``new'' changes on master back into the feature branch (and any other branch you are working on).