Thanks for starting a comprehensive thread on these subjects.  I probably have more questions than answers, but maybe they'll be worthwhile.<br><br><div><br><div class="gmail_quote">On Tue, May 18, 2010 at 1:13 PM, Ilya Haykinson <span dir="ltr"><<a href="mailto:haykinson@gmail.com">haykinson@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><br></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><br></div><div>Assuming agreement on the above (not a given, but I wanted to explore further), there are some open questions with this approach:</div>
<div><br></div><div> - What data format should we use for storage?</div></blockquote><div><br></div><div><br></div><div>Seems like DocBook has the most flexibility, but since there is some barrier to entry when writing DocBook maybe it'd be worth the time to come up with some kind of simple editing tool.  That is if there isn't something out there better than Gedit :-).</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div> - What should be the backing store for this data?</div></blockquote><div><br></div><div>

<br></div><div>bzr and LP make sense to me... I'll continue below.  Using tools like Ground Control should help with merging, proposed merges, etc.  Does Ground Control allow you to file bugs against branches?</div><div>

<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><br></div>
<div>Candidates for backing store:</div><div><br></div><div> - Database</div><div>   - Pros: we can design whatever storage structure we want; easier to search or query; can store metadata alongside data; could work well with review queues</div>


<div>   - Cons: we'd have to build an RCS-style system within a DB; harder to contribute offline (can't check out the whole corpus)</div><div> - RCS like bazaar or git</div><div>   - Pros: already-built RCS; strong support for changesets; able to check out whole corpus and work offline; easier to write file-based tools</div>


<div>   - Cons: poor storage of metadata; poor query ability</div><div><br></div></blockquote><div><br></div><div><br></div><div>Can you elaborate more on what metadata you're looking to store?  </div><div><br></div>

<div>In my very humble opinion, using an RCS for is much preferable to straight database. From working on the Server Guide content for a while now, having the ability to roll back changes and see diffs between files is very necessary.</div>

<div><br></div><div>The hybrid approach may make sense though.  If you could store information about a commit based on revision number... there's probably some type of bzr hook that could add entries to a database.</div>

<div><br></div></div>Just my quick thoughts, thanks again.<br clear="all"><br>-- <br>Party On,<br>Adam<br>
</div>