<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hi Markus,
<div class=""><br class="">
</div>
<div class="">I agree with the general sentiment that keeping of repository clean would make it easier to use, especially with respect to removing (or maybe just moving) files that are not longer relevant. &nbsp;I think the guidelines you mention below make sense,
 but not in all circumstances, so I offer a few counterpoints below.</div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">Tom</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Apr 5, 2017, at 8:28 AM, Markus Demleitner &lt;<a href="mailto:msdemlei@ari.uni-heidelberg.de" class="">msdemlei@ari.uni-heidelberg.de</a>&gt; wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Dear Mark, Dear everyone-else-who-as-stuff-in volute/.../DM,<br class="">
<br class="">
I got hold of some time series data and would now like to write a<br class="">
prototype service for these. &nbsp;I'd like this to spit out something as<br class="">
close to current drafts, Jiris proposal, SPLAT implemenation, and my<br class="">
hopes at the same time. &nbsp;For that, it would be great if I had a<br class="">
blueprint of the &quot;current upstream idea&quot;, as it were. &nbsp;So,<br class="">
<br class="">
On Mon, Mar 27, 2017 at 05:38:55PM -0400, CresitelloDittmar, Mark wrote:<br class="">
<blockquote type="cite" class="">I have 'mocked' the resulting model changes and generated some example<br class="">
files:<br class="">
&nbsp;1) chandra event list (real-world cube file)<br class="">
&nbsp;2) timeseries example from the Note.. Figures 5, 6, 7<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with added detail about the CoordSys, Frames, etc.<br class="">
</blockquote>
<br class="">
Are these files available now? &nbsp;If so, where?<br class="">
<br class="">
<br class="">
But since I just stumbled around in the DM tree in volute, I've<br class="">
accumulated some additional requests as regards its (particular)<br class="">
contents. &nbsp;They come mainly with my user hat on (at least for me, it<br class="">
is *very* hard to figure out what's what right now), but a little bit<br class="">
of what's on my head is also coming from me as operator; everything's<br class="">
much easier for a VCS (and makes more sense) if the amount of binary<br class="">
data is a low as it can possibly be.<br class="">
<br class="">
(1) volute is a VCS, so it does versioning by itself. &nbsp;It would<br class="">
therefore be great if you just kept the latest version of each<br class="">
document in there and *not* use version number in file names. &nbsp;If<br class="">
people actually want to go back in time, they can use the standard<br class="">
svn mechanisms (svn log, svn co -r...; yes, with office files there<br class="">
are no diffs, which is regrettable, but the full files are still<br class="">
there). &nbsp;That would already clean up a directory like<br class="">
<a href="http://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/doc/" class="">http://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/doc/</a> very nicely.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>When we’re creating “official” documents, the process requires the files tracked on
<a href="http://ivoa.net" class="">ivoa.net</a>&nbsp;to include version numbers in the names, and I think it makes sense to have the working copies in volute match those official file names. &nbsp;We could rename the files as they make their way through the process without
 losing VCS history, but a decent alternative might be to create an ‘archived’ directory where we could move all files that are no longer being edited. &nbsp;That would keep the working directory clean but allow fairly easy perusal of the document history.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
(2) Being a VCS, I think volute should not be polluted by things that<br class="">
aren't &quot;source&quot; but can be generated from things in volute. &nbsp;In<br class="">
particular, I don't think &quot;baked&quot; PDFs should be in there. &nbsp;They are<br class="">
almost certain to cause version conflicts, and there's no added value<br class="">
in having them in a VCS. &nbsp;And no, putting PDFs into volute don't<br class="">
really improve any of the issues associated with using docx…</div>
</div>
</blockquote>
<div><br class="">
</div>
I generally I agree that “baked” files don’t belong in VCS, but I think it’s a legitimate exception when we want the “baked” files to be easily URL accessible. &nbsp;Some of these PDFs may fall into that category.</div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
(3) It'd be great if there was a top-level readme explaining where<br class="">
things are supposed to be (there's vo-dml/README.txt that goes a long<br class="">
way, but how does that relate to the rest of the dm tree?). &nbsp;Right now,<br class="">
if I look for, say, the vo-dml of Dataset, where do I go? &nbsp;Is<br class="">
<a href="http://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/models/" class="">http://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/models/</a> the right<br class="">
place? &nbsp;Or<br class="">
<a href="http://volute.g-vo.org/svn/trunk/projects/dm/DatasetMetadata-1.0/model/?" class="">http://volute.g-vo.org/svn/trunk/projects/dm/DatasetMetadata-1.0/model/?</a><br class="">
In the latter directory, there's even a zip file -- that in turn<br class="">
contains a project.conf that says &quot;GENERATED FILE, PLEASE DO NOT<br class="">
EDIT!!!&quot; [all the bangs included] -- does something like this really<br class="">
have to be under version control?<br class="">
<br class="">
(4) Lastly, again since volute is a VCS, it would be great if you<br class="">
could just delete from trunk the traces of efforts that are pretty<br class="">
certainly abandoned (e.g., ImageDM, I guess, SpectralDM-2.0 as well).<br class="">
These things can always be recovered from the history if really<br class="">
necessary, and if you think they must be visible somewhere in<br class="">
HEAD, just make a tag containing whatever is going on (e.g.<br class="">
<br class="">
svn copy http://volute.g-vo.org/svn/trunk/projects/dm/SpectralDM-2.0/ \<br class="">
http://volute.g-vo.org/svn/tags/DM-attic/SpectralDM-2.0-as-abandoned<br class="">
svn remove http://volute.g-vo.org/svn/trunk/projects/dm/SpectralDM-2.0/<br class="">
<br class="">
All of that would really help usability of the dm subtree in volute.<br class="">
<br class="">
Thanks,<br class="">
<br class="">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Markus<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>