suggestions for version control or backup systems?

Sebastian

unread,

Oct 4, 2010, 6:04:58 AM10/4/10

to

Hi,
I've been searching for a way to keep my nb-files in a version control
or backup system for a while now. At the moment I'm using bzr but I'm
not satified with it, as I managed to screw up my repository 2 times
now. I'm considering to move to git or mercurial as they may be more
suited to handle binary files.
Does anyone have any suggestions? How do you all handle your notebook
files?
Cheers
Sebastian

Albert Retey

unread,

Oct 5, 2010, 5:34:40 AM10/5/10

to

Hi,

I've been using subversion and mercurial, no screwed up repositories or
anything really bad happend to me with either of them. But I usually
only put relatively small notebooks with deleted output cells into
version control, so your milage might vary...

hth,

albert

Sebastian

unread,

Oct 6, 2010, 3:13:47 AM10/6/10

to

The main problem I encounter is that bzr tries to merge my nb files,
which of course differ a lot from each other because of different
output cells, etc. It then screws up the nb by placing markers which
are supposed to help you resolve the conflict, which of course is just
a pain! So I want a vcs which handles binary files better and
preferably doesn't screw them up. Maybe I should also think of
deleting my output cells, on the other hand it may take some time to
recreate them... Anyway, thanks for your heads up on hg!

Cheers,
Sebastian

Simon

unread,

Oct 6, 2010, 3:15:44 AM10/6/10

to

I think that git is probably the best version control system out there
at the moment (though I think bazaar and mercurial are also good).
Anyway, it's hard to argue with Linus! http://www.youtube.com/watch?v=4XpnKHJAok8

If you've got a large project, it might be best to work on the package
file (.m) separately - as opposed to auto-generating it from a
notebook. Then version control is quite simple, as there is less
automatically generated metadata. Also, maybe consider using Wolfram
Workbench (based on eclipse).

As for the notebook, to prevent too many changes being logged and
reduce the number of merge issues you should turn off the notebook options
TrackCellChangeTimes and FileOutlineCache -- they can be found in the
option inspector.
You could also use the script at http://www.itwm.fraunhofer.de/as/asemployees/wichmann/nbcache.html

Finally you should go to
http://stackoverflow.com/questions/2816628/version-control-of-mathematica-notebooks
and vote up the accepted answer!

Simon

Albert Retey

unread,

Oct 7, 2010, 3:37:26 AM10/7/10

to

Hi,

> The main problem I encounter is that bzr tries to merge my nb files,
> which of course differ a lot from each other because of different
> output cells, etc. It then screws up the nb by placing markers which
> are supposed to help you resolve the conflict, which of course is just
> a pain! So I want a vcs which handles binary files better and
> preferably doesn't screw them up. Maybe I should also think of
> deleting my output cells, on the other hand it may take some time to
> recreate them... Anyway, thanks for your heads up on hg!

The merging problem will probably exist for every vcs out there, since
almost every vcs I know or have heard of works in a line oriented way. I
think there are alternatives, which try to store and compare some kind
of interpreted expression instead of plain text, but I am quite sure
there is none that understands the internals of notebooks (or
mathematica expression syntax in general). It would maybe be an
interesting task to implement something like that in Mathematica itself :-)

As far as I remember both svn and hg -- and probably most other vcs --
do this kind of automatic merging but also can just extract the two
versions that conflict so you can do the merging by hand, I do that once
in a while with the NotebookDiff-Utility from the old AuthorTools
package. Maybe you will need some configuration or extra commands to
check out the two conflicting versions instead of the one with the
conflict marks.

So the problem you had will not be solved by using another vcs, but
maybe you will find it easier to configure one of them to not even try
the automatic merges. With newer version I find it a reasonable approach
to edit .m files in the frontend, which has the advantage that these can
be treated as regular text code files by a vcs, so you will even be able
to take advantage of automatica merges...

hth,

Albert

Sebastian

unread,

Nov 4, 2010, 5:01:55 AM11/4/10

to

Thanks for all your help! I just noticed that I already replied
(twice!) to your answers, but the messages didn't get through!
Crossing my fingers for better luck this time! s