Take the 2-minute tour ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

I am considering a project using Mathematica and openCL. I know that the openCL C source code can be tracked.

Has anyone used a versioning site or software so multiple developers can modify a common notebook? Is it possible to:

  • check out a notebook non-exclusively?
  • check out a notebook exclusively?
  • change the notebook?
  • merge a notebook locally?
  • check in a notebook?
share|improve this question
1  
I use Eclipse + Workbench plugin + SVN. –  b.gatessucks Sep 29 '12 at 9:48
2  
@FredDanielKline there is already a proposal for the community to migrate that question on SO. If that is supported, then we can merge your question with that one once it's migrated. –  Verbeia Sep 29 '12 at 11:15
1  
I've experienced that under Linux, if you check in a notebook to an SVN archive while it is open in Mathematica, Mathematica has problems (I don't remember exactly because it's some time since I experienced it, but IIRC I had to restart Mathematica). I have no idea what SVN does to the file on checkin (I would have expected it to only read the file for checking in), but whatever it is, Mathematica doesn't like it. With Mercurial, I didn't have such problems. Note that a checkout while the notebook is open in Mathematica is never a good idea. –  celtschk Sep 29 '12 at 16:07
1  
I thought about such a solution for a while, never came up with a satisfactory answer, however. There is just too much metainformation in nb files, which is of no real relevance for the code you actually want to check into a VCS. I resorted to keeping packages I write (as m files only) in git, while keeping regular backups of all nb files. Of course you could also save the nb as m file (therefore discarding all metainformation) and check that into your VCS. I just never found that a practical approach. –  sebhofer Sep 29 '12 at 17:14

4 Answers 4

up vote 13 down vote accepted

First, if you want to have a team working on Mathematica code, then you really should do it properly and use Wolfram Workbench. As pointed out by Leonid, notebooks are not the right tool for software development.

This said, I have used version control (git) with a notebook and successfully merged versions. To do it, I minimized the amount of metadata in the notebook by:

  1. Turning off Notebook History (and clearing any existing history using the dialog)
  2. Turning off the Notebook Cache (in the option inspector).

You can turn off both notebook options with with the single command

SetOptions[InputNotebook[], 
 PrivateNotebookOptions -> {"FileOutlineCache" -> False}, 
 TrackCellChangeTimes -> False]

but clearing the existing notebook history (removing all of the CellChangeTimes cell options) is easiest using the provided dialog.

Outputs can be long and messy and normally don't want to be tracked by your VCS. Some input/ouput combinations I did want to keep, so I set the output cell option GeneratedCell->False and then both cells' options to make them non-deletable and non-editable. The rest of the output cells were removed using the Delete All Output menu option.

Finally, keep your notebook(s) well organised with sections and subsections so that work and changes are clearly localised, which will make possible merges easier.

share|improve this answer
    
Very good points,+1. Good to see you answering, it's been a long time. –  Leonid Shifrin Sep 30 '12 at 13:34
    
@Leonid Thanks! –  Simon Oct 2 '12 at 8:48

Not a full answer, but too long to fit in a comment, will delete when this is settled. Also notice that Eclipse > 3.7.2 doesn't work with the Workbench plugin. The setup Eclipse+Workbench plugin+SVN works well when sharing packages (.m) but I have little experience doing it with notebooks.

I setup a quick example trying to answer the comment by @Nasser but I'm not sure if this is satisfactorily; please see first screenshot.

Regarding merging, I think there is at least a basic functionality; again, not sure if this is exhaustive enough; please see second screenshot.

ss1 ss2

share|improve this answer

If you plan to start a project with several developers involved, I would not base it on notebooks, because, as was mentioned by others, notebooks contain too much metadata. If you open a notebook file in a text editor, you will see that the actual code in the input cells only occupies a small fraction of the total file's size.

Besides, notebooks are aimed at a very different goal: explorations, interactive visualizations, and perhaps rapid prototyping. They are not aimed at structuring and maintaining code bases, at least not without some extra framework built on top of the core notebook interface.

I would definitely recommend the toolchain containing Wolfram Workbench (which is based on Eclipse and integrates with CVS and SVN), Mathematica packages,and the MUnit package for unit tests. Packages contain just code, are in plain ASCII files, and are well-suited for versioning. Developers can still use notebooks for interactive development, but I would not do shared work with notebooks. I would rather use them in two other capacities where they shine:

  • Exploration and prototyping medium for individual developers (don't have to be shared)
  • A medium of communication: one developer can create a notebook with illustrations, and send to others or commit that under his / her own sub-project. Others can use that to quickly see things, but would not modify it.

Of course, I don't mean to suggest that notebooks should never be shared and jointly modified, but if you reduce that to a minimum, you will avoid most of the merging problems involving them.

The bottom line of my message here is that code should be separated from the environment which has nothing to do with the problem that the code solves directly. The less metadata you will have hanging around the better it will be, because this metadata creates serious mental overhead for the developers. For any project except most trivial ones, this overhead will actually be much larger than the one associated with learning and using Workbench and related tools. And, the Workbench is integrated with Mathematica /FrontEnd sufficiently tightly that you don't lose the advantages notebooks give you - interactivity, rapid prototyping, etc.

share|improve this answer
1  
@NasserM.Abbasi That depends on the definition of useful work. If you have a project with more than one developer, it is likely to eventually have a moderately large code base. In such a case, different modules developed by different developers should have clear interfaces separated from their implementations. Those interfaces must be agreed upon, by the developers. In any case, my point is that the notebooks should not contain serious work to be shared. If the interface of a given module changes, it is dev's responsibility to update the notebook, if that is at all necessary. –  Leonid Shifrin Sep 29 '12 at 21:35
    
@NasserM.Abbasi The whole point of separation between interface and implementation, which is central to software development, is exactly to decouple implemetation changes from the use cases. If someone checks out some module and changes implementation, that should not affect the usage (notebook). While if someone changes also the interface, then it is a bad separation of duties: any given interface should IMO be "owned" (in the sense of write access) by only the developer who works on that module. –  Leonid Shifrin Sep 29 '12 at 21:38

I lack the reputation to comment on a different answer so I must write my own answer (how perverse!).

Let me add to what simon wrote.

First, there need to be quotes around "TrackCellChangeTimes" in the code he wrote here or else it enters the Notebook's options as something like CellContext`TrackCellChangeTimes.

Second, it is possible to programmatically clear the CellChangeTimes from a notebook. Here is one approach:

CleanNotebook[nb_NotebookObject] := Module[{},
  SetOptions[nb, 
   PrivateNotebookOptions -> {"FileOutlineCache" -> False}, 
   "TrackCellChangeTimes" -> False];
  SetSelectedNotebook[nb];
  SelectionMove[nb, All, Notebook];
  FrontEndExecute[{FrontEnd`RemoveOptions[FrontEnd`SelectionObject, 
     "CellChangeTimes"]}]
  ]

The last three commands come from inspecting the system file ./SystemFiles/FrontEnd/SystemResources/HistoryOverview.nb in the Mma distribution; that is the code for the palette which lets you inspect the CellChangeTimes.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.