Re: command to save as .m file
- To: mathgroup at smc.vnet.net
- Subject: [mg113780] Re: command to save as .m file
- From: John Fultz <jfultz at wolfram.com>
- Date: Fri, 12 Nov 2010 05:27:38 -0500 (EST)
On Thu, 11 Nov 2010 06:10:25 -0500 (EST), Sebastian wrote:
> On Nov 10, 12:28 pm, John Fultz <jfu... at wolfram.com> wrote:
> Hi John,
> thanks for your extensive reply!
>
>> Yes, you can do this, and I'll show you how...but I'm confused about
>> something. I'm not fully convinced by your revision control strategy.
>> Either your notebooks really are the source document, in which case, you
>> should keep them under source control regardless of the difficulties.
>> Or the packages really are the source document, in which case you should
>> be opening/editing/saving them as packages natively (i.e., using
>> Workbench and/or the front end's package editor...which play very nicely
>> with each other, I might add), and never as notebooks.
> I'm also not fully convinced by this strategy and I will likely change
> it in the future. What I am convinced of is, that putting notebook
> files under revision control is a major pain. Either that or I'm just
> doing it wrong. I would be grateful for suggestions how to handle
> merge conflicts of nb files! Resolving them seems to be a nearly
> impossible task and generally not worth the time and hassle! The only
> option I see is not to merge nb files at all, which kind of defies the
> point of using revision control. So my strategy is twofold:
> 1) Separate code from output/plots... as much as possible
> 2) If this is not possible, work on the nb file, save as package and
> check that into revision control. If something has to be merged I can
> resave to a nb file, which works reasonably well I think... or does it
> not?
Merge conflicts are not easy to deal with for notebooks. They can be minimized
by working with notebooks without file outline caches. If you set the
PrivateNotebookOptions->{"FileOutlineCache"->False} option on an individual
notebook, then the file outline cache drops away. Which means that it loads
more slowly, but also gets rid of the guaranteed source of merge conflicts.
What remains does, sometimes, merge successfully. When it fails, things are
still going to be very bad, but it does at least succeed sometimes. And
possibly quite often, depending upon the kinds of changes being made to the
notebook.
>> Putting generated artifacts under source control...and generating
>> artifacts is precisely what Save As->Package from a notebook does...is
>> generally ill- advised and exposes you to either the loss of your source
>> material, or synchronization problems with that source material.
> What do you mean by "generated artifacts"? Why does saving to a
> package generate artifacts? I am completely lost here, please
> elaborate!
Let me start with a simple explanation which you may already understand, but
just to make sure we're on the same page. There's a general principle in
version control that you try to put only sources, not built objects or, as I'm
calling them, generated artifacts. If you were working with Java, you would put
.java files under source control, but not .class or .jar files. If you were
working with C/C++, you'd put .c/.cpp/.h/.hpp files under source control, but
not .obj/.a/.exe/.lib/.so/.dll files.
When you're working with notebooks as the source medium, and you do File->Save
As->Package, you are generating that package file from something which is *not*
the source. It may not be compiled, but it's generated all the same. And
you're losing information, and risking the possibility of things getting out of
sync.
The Mathematica front end has a quite nice package editor. Perhaps you're not
aware of this, but the front end's package editor can preserve quite a lot of
style and cell group structure with simple comments which are not cumbersome
when you see them in Workbench or a text editor (in fact, they can be
enlightening!). At Wolfram, some people prefer working in the package edit or
and use it in preference to working in other environments because it maintains a
very notebook-like environment while working much closer to the plain text model
of package files. In their case, the package file is the *primary* source file,
not a secondary file generated by a conversion step. But it doesn't preserve
outputs, which you seem to be suggesting you're looking for.
>> Alternatively, you could also set the AutoGeneratedPackage option in the
>> Option Inspector for the given notebooks, which could force them to
>> always save a synchronized package file...although this even more
>> greatly magnifies the "generated artifact" problem I outlined above.
> This is actually what I would like to use, but the auto generated
> packages only include initialization cells, which is not enough.
Oh, yes...sorry, forgot about that.
>
> Best regards,
> Sebastian
Sincerely,
John Fultz
jfultz at wolfram.com
User Interface Group
Wolfram Research, Inc.