# Latest documents online **Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158) **Created:** 2007-02-28 01:16 UTC **Views:** 2 **Replies:** 9 **URL:** https://discourse.openehr.org/t/latest-documents-online/14626 --- ## Post #1 by @thomas.beale Nearly all openEHR specifications are online in their latest form at http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/index.html Don't bother looking at the "in\-development" ones \- they have not gone up yet; the XML\-schema, UML and terminology are being updated to conform\. All feedback welcome; these are very close to the final versions for openEHR Release 1\.0\.1 \- thomas --- ## Post #2 by @erik.sundvall Hi\! > Nearly all openEHR specifications are online in their latest form at > http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/index.html > > All feedback welcome; these are very close to the final versions for > openEHR Release 1\.0\.1 The versioning is a bit confusing: \- In the last quoted sentence above 1\.0\.1 \- In the link above 1\.1 \- The header of the linked page "openEHR Specification Project Release 1\.0\.1 Document Road Map" \- The "UML computable form of model" linked from the roadmap says "The models shown here are are derived from the official openEHR Release\-1\.1 candidate \(contains a small number of changes with respect to Release\-1\.0\. PDF specifications\)\." \-Under http://svn.openehr.org/specification/BRANCHES/ there are only 1\.0 and 1\.1 no 1\.0\.1 Are there 1\.1 documents and artifacts being worked on simultaneously as the final release of 1\.0\.1 or are the as authors confused as I am? Another \(partly unrelated\) confusing thing is that the PDFs sometimes get updated content during development without having document numbers, dates or change history adjusted\.If at least the date was changed it would be a lot easier to check if documents printed on paper are up to date or not\. Best regards, Erik Sundvall http://www.imt.liu.se/~erisu/ --- ## Post #3 by @system Erik Sundvall schreef: > Hi\! > >> Nearly all openEHR specifications are online in their latest form at >> http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/index.html >> >> All feedback welcome; these are very close to the final versions for >> openEHR Release 1\.0\.1 >>     I agree with Erik\. \(say this to make the matter more urgent\) \(confusing versions\) But, besides this, I am glad the documentation project reaches its final version release\. it gives me as developer a steady target\. Bert --- ## Post #4 by @thomas.beale Erik Sundvall wrote: > Hi\! > >> Nearly all openEHR specifications are online in their latest form at >> http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/index.html >> >> All feedback welcome; these are very close to the final versions for >> openEHR Release 1\.0\.1 >>     > The versioning is a bit confusing: > \- In the last quoted sentence above 1\.0\.1 > \- In the link above 1\.1 >   yes, this has been there for 12 months \- it was an error when I created the branch \(should have been 1\.0\.1\)\. The only reason I have not changed it is that I am not sure how well Subversion will handle such a rename \- my concern is that it will cause a massive copy\.\.\.\.does anyone happen to know? Rename of a directory is an option in Subversion of course, but my impression is that it doesn't work the way it should \- it seems to do a huge copy kind of action\.\.\.\.I should run some tests I guess > \- The header of the linked page "openEHR Specification Project Release > 1\.0\.1 Document Road Map" > \- The "UML computable form of model" linked from the roadmap says "The > models shown here are are derived from the official openEHR > Release\-1\.1 candidate \(contains a small number of changes with respect > to Release\-1\.0\. PDF specifications\)\." > \-Under http://svn.openehr.org/specification/BRANCHES/ there are only > 1\.0 and 1\.1 no 1\.0\.1 >   yes \- so to be clear \- the next release is Release 1\.0\.1 \- the '1\.1' thing is just an error in the Subversion repository branch name which I have not been game to fix for the above reason\. > Are there 1\.1 documents and artifacts being worked on simultaneously > as the final release of 1\.0\.1 or are the as authors confused as I am? > > Another \(partly unrelated\) confusing thing is that the PDFs sometimes > get updated content during development without having document > numbers, dates or change history adjusted\.If at least the date was > changed it would be a lot easier to check if documents printed on > paper are up to date or not\. >   We are pretty careful with this, although I know there have been exceptions; the document dates always get changed; the version number does not \(otherwise we would have endless versions just due to the review process\); the change history is almost always updated unless the change is a typo or similar\. We have used a new style of front page to make this information easier to see\. Hope that helps somewhat\. \- thomas --- ## Post #5 by @erik.sundvall Hi\! Nice that the 1\.0\.1 is coming closer to release\. Good work\! > > \- The "UML computable form of model" linked from the roadmap says "The > > models shown here are are derived from the official openEHR > > Release\-1\.1 candidate \(contains a small number of changes with respect > > to Release\-1\.0\. PDF specifications\)\." I noticed that the error above comes from the fact that the "UML computable form of model" link on the page\.\.\. http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/index.html \.\.\.points to\.\.\. http://svn.openehr.org/specification/TRUNK/publishing/architecture/computable/UML/uml.html \.\.\.on TRUNK instead of the release branch as the other documents on the page\. It should point to: http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/computable/UML/uml.html that containts the less confusing text ;\-\) The subversion error probably needs to be fixed before some future 1\.1 release anyway so why not fix it before the 1\.0\.1 release instead\. That may save some confusion in the long run\. I guess the only alternative would be to skip 1\.0\.1 and call the imminent release 1\.1 instead, but that will probably be a worse solution crating even more confusion\. Best regards, Erik Sundvall http://www.imt.liu.se/~erisu/ --- ## Post #6 by @Andrew_Patterson > the branch \(should have been 1\.0\.1\)\. The only reason I have not changed > it is that I am not sure how well Subversion will handle such a rename \- > my concern is that it will cause a massive copy\.\.\.\.does anyone happen to > know? Rename of a directory is an option in Subversion of course, but my > impression is that it doesn't work the way it should \- it seems to do a > huge copy kind of action\.\.\.\.I should run some tests I guess A rename operation will appear to copy/delete every item at the client end \- however, at the server end subversion is very smart and effectively performs the operation without actually copying any of the data\. It uses the same technique that Subversion uses for performing tagging/branching \(which is a server 'copy' operation that doesn't actually duplicate the data on the server\)\. So there is no problems with the repository growing\. The only gotcha is its behaviour if there are modified descendants of the directory you are renaming\. It may just be the clients but I seem to remember them not being handled so well \- so just make sure everything is committed before renaming\. Andrew --- ## Post #7 by @thomas.beale Andrew Patterson wrote: >> the branch \(should have been 1\.0\.1\)\. The only reason I have not changed >> it is that I am not sure how well Subversion will handle such a rename \- >> my concern is that it will cause a massive copy\.\.\.\.does anyone happen to >> know? Rename of a directory is an option in Subversion of course, but my >> impression is that it doesn't work the way it should \- it seems to do a >> huge copy kind of action\.\.\.\.I should run some tests I guess >>     > A rename operation will appear to copy/delete every item > at the client end \- however, at the server end subversion is > very smart and effectively performs the operation without > actually copying any of the data\. It uses the same > technique that Subversion uses for performing > tagging/branching \(which is a server 'copy' operation that > doesn't actually duplicate the data on the server\)\. So there > is no problems with the repository growing\. The only gotcha > is its behaviour if there are modified descendants of the > directory you are renaming\. It may just be the clients but > I seem to remember them not being handled so well \- so > just make sure everything is committed before renaming\. >   Hm\. I wonder what would happen if I went to the server and did a rename using a command line command there? How would the clients react n their next 'update'? \- thomas --- ## Post #8 by @system Thomas Beale schreef: > Andrew Patterson wrote: >   >>> the branch \(should have been 1\.0\.1\)\. The only reason I have not changed >>> it is that I am not sure how well Subversion will handle such a rename \- >>> my concern is that it will cause a massive copy\.\.\.\.does anyone happen to >>> know? Rename of a directory is an option in Subversion of course, but my >>> impression is that it doesn't work the way it should \- it seems to do a >>> huge copy kind of action\.\.\.\.I should run some tests I guess >>>     >> >> A rename operation will appear to copy/delete every item >> at the client end \- however, at the server end subversion is >> very smart and effectively performs the operation without >> actually copying any of the data\. It uses the same >> technique that Subversion uses for performing >> tagging/branching \(which is a server 'copy' operation that >> doesn't actually duplicate the data on the server\)\. So there >> is no problems with the repository growing\. The only gotcha >> is its behaviour if there are modified descendants of the >> directory you are renaming\. It may just be the clients but >> I seem to remember them not being handled so well \- so >> just make sure everything is committed before renaming\. >>   > > Hm\. I wonder what would happen if I went to the server and did a rename > using a command line command there? How would the clients react n their > next 'update'? >   My client would create a new directory, as it always does as it gets a new directory offered\. I will delete the old one manually, no problem\. bert --- ## Post #9 by @Andrew_Patterson > My client would create a new directory, as it always does as it gets a > new directory offered\. > I will delete the old one manually, no problem\. Even better than that, as long as Bert has no local modifications in his tree, it will delete the old directory for him properly\. It will even retain file histories for all files in the renamed directories \(and the directories themselves \- you could check out an old revision and it will correctly make the old directory\)\. The subversion directory handling is really quite good\. Andrew --- ## Post #10 by @thomas.beale Andrew Patterson wrote: >> My client would create a new directory, as it always does as it gets a >> new directory offered\. >> I will delete the old one manually, no problem\. >>     > Even better than that, as long as Bert has no local modifications in > his tree, it will delete the old directory for him properly\. It will > even retain file histories for all files in the renamed directories > \(and the directories themselves \- you could check out an > old revision and it will correctly make the old directory\)\. The > subversion directory handling is really quite good\. >   do you know this for a fact? I retain memories of when it was not so good\! \- thomas --- **Canonical:** https://discourse.openehr.org/t/latest-documents-online/14626 **Original content:** https://discourse.openehr.org/t/latest-documents-online/14626