Hi,<div><br></div><div>Yes Smallworld did a lot of innovation in the area of version management and long transactions some 20 years ago, I was quite involved in all that. The technical paper you mention is at <a href="http://archive.org">archive.org</a>, a great resource for finding web pages that have disappeared!</div>
<div><a href="http://web.archive.org/web/20080519210011/http://cfis.savagexi.com/pages/technical_paper_4">http://web.archive.org/web/20080519210011/http://cfis.savagexi.com/pages/technical_paper_4</a></div><div><br></div>
<div>This paper, which I was a co-author of, talks about long transactions as well as query architectures:</div><div><a href="http://web.archive.org/web/20070828091638/cfis.savagexi.com/pages/technical_paper_8">http://web.archive.org/web/20070828091638/cfis.savagexi.com/pages/technical_paper_8</a></div>
<div><br></div><div>The whole list of Smallworld technical papers is at</div><div><a href="http://web.archive.org/web/20080519210016/cfis.savagexi.com/pages/technical_papers">http://web.archive.org/web/20080519210016/cfis.savagexi.com/pages/technical_papers</a></div>
<div><br></div><div>ESRI, Oracle and others adopted a number of the version management ideas that Smallworld pioneered, but (IMHO) still don't have nearly as robust an implementation as Smallworld does. If anyone has questions on this area, I'm happy to try to answer them. If you're not familiar with Smallworld, there's a bit more background on my blog at <a href="http://bit.ly/cDUid1">http://bit.ly/cDUid1</a></div>
<div><br></div><div>Cheers,</div><div> Peter.<br><br><div class="gmail_quote">On Fri, Sep 24, 2010 at 3:55 AM, STEPHEN STANTON <span dir="ltr"><<a href="mailto:sstanton@btinternet.com">sstanton@btinternet.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
I'm a bit surprised no-one mentions Smallworld. Weren't they at the forefront of version management almost 20 years ago?<br>
<br>
The following link to an interesting technical paper isn't currently working, but maybe it'll come back later: <a href="http://cfis.savagexi.com/pages/technical_paper_4" target="_blank">http://cfis.savagexi.com/pages/technical_paper_4</a><br>
<br>
Steve<br>
<div><div></div><div class="h5"><br>
> On 09/24/2010 01:40 AM, Bruce Bannerman wrote:<br>
> > Ragi,<br>
> ><br>
> > I agree. I think that we have a way to go yet to have<br>
> something<br>
> > comparable to the ArcSDE / ArcGIS Multi-versioning and<br>
> version conflict<br>
> > detection functionality.<br>
> ><br>
> > The advantage that the ArcSDE solution has is that<br>
> edits are made<br>
> > directly within the database. This works well within<br>
> an Enterprise<br>
> > environment as described by Fabio earlier in this<br>
> thread.<br>
> ><br>
> > I may be wrong, but I think that git works on files,<br>
> but I haven’t used<br>
> > it myself. Can git detect changes to the spatial<br>
> representation of a<br>
> > feature within a binary file?<br>
> ><br>
> > Also, speaking as someone who implemented an<br>
> ArcSDE/ArcGIS<br>
> > Multi-versioned edit scenario several years ago, the<br>
> ESRI solution is<br>
> > far from perfect. It imposes very strict environment<br>
> management on the<br>
> > system managers, e.g.:<br>
> ><br>
> > * All versions of the software<br>
> used (client and server) must be at<br>
> > precisely the same<br>
> version, service pack and patch;<br>
> > * The environment can only use<br>
> software that implements the<br>
> > ArcObjects environment<br>
> (from experience, this rules out the use of<br>
> > the ArcSDE Java and C<br>
> API’s);<br>
> > * Editors must be well trained<br>
> and knowledgeable in using both<br>
> > ArcGIS and<br>
> Multi-versioned processes;<br>
> > * The Organisation needs to<br>
> think through their maintenance<br>
> > processes to get best<br>
> advantage of the functionality; and<br>
> > * It doesn’t remove the need<br>
> for data maintenance people to talk to<br>
> > each other about work<br>
> that is going on, as the software cannot<br>
> > resolve all conflicts.<br>
> For example, if two editors make changes to<br>
> > the spatial<br>
> representation of a feature, which one is correct? The<br>
> > software will detect<br>
> the conflict, but the editors (or their<br>
> > managers) will need to<br>
> resolve the issue of which version of the<br>
> > feature’s spatial<br>
> representation is correct.<br>
> ><br>
> ><br>
> ><br>
> > Bruce<br>
<br>
<br>
</div></div><div><div></div><div class="h5">_______________________________________________<br>
Discuss mailing list<br>
<a href="mailto:Discuss@lists.osgeo.org">Discuss@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>
</div></div></blockquote></div><br></div>