hi fernando,<div><br><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I also don't want to lock anyone in the 'app' view of the<br>


world.  If anyone has notebooks that are part of an existing project<br>
with its own version control setup, then that's where the VC belongs,<br>
not in the notebook app.  </blockquote><div><br></div><div>fair enough. one should carefully consider if it's a file format that's just for the notebook 'app' and a general file format that could be: a) used throughout ipython (e.g., run/load blah.ipynb) and b) enable efficient vc. </div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">For that use case, the notebooks are just<br>
another type of file, next to python scripts, text files and anything<br>
else that may be part of that project.  There's no reason why users in<br>
that scenario should be forced to manage the notebooks differently<br>
from their other files in the project.<br></blockquote><div><br></div><div>but users are forced to manage vc of notebooks differently in any of the proposed scenarios.</div><div><br></div><div>1. one file (effectively binary)</div>

<div>if i put it under a vc, it's simply a revision control history. no easy way to look at diffs beyond simple ones.</div><div><br></div><div>2. split (text + cache)</div><div>if i want exact reproducibility of loading i need to have both under simultaneous version control. the chances of desynchronization are very high. and this would definitely benefit from an app-integrated vc.</div>

<div><br></div><div>3. split (keep text only)</div><div>easy vc, but requires exact environment (data+libraries) for reproducibility.</div><div><br></div><div>i would vote for allowing any of the above through configurable options as different people may have different use-cases.</div>

<div><br></div><div>cheers,</div><div><br></div><div>satra</div><div> </div></div></div></div>