Hi At Sun, 15 Nov 2009 10:48:09 +0300, Vasily Vl. Suhachev wrote:

We are using Mercurial distributed VCS. Main repository maintained by myself, other contributors bring changes to me on flash-cards or send patch-files by email

OK, nobody has mentioned git yet, so I'll do it. Frankly I have never really used bazaar or hg (mercurial), but all three are very similar in many respects. For the purpose of tracking files and exchanging them with collegues, only decentralized VC makes sense (maybe with a central repository, but that is not important). CVS is dead, SVN is not very good for that purpose. Two nice short introductions: http://www-cs-students.stanford.edu/~blynn/gitmagic/ http://wiki.sourcemage.org/Git_Guide Have fun Martin

Hi again At Sun, 15 Nov 2009 12:49:46 -0700, Aaron Birenboim wrote:

...

For the purpose of tracking files and exchanging them with collegues, only decentralized VC makes sense (maybe with a central repository, but that is not important). CVS is dead, SVN is not very good for that purpose.

Huh? That is the primary purpose of SVN, AFAIK.

SVN is great for centralized data repositories. I used to use it for several years for all my data, basically synchronizing laptop and desktop, and collaboration on projects. The major drawback (for me) is that you need a connection to the server with the central repository to commit changes. After having switched to git (any distributed VC such as hg or bzr will do), I commit every non-trivial editing/work step locally, and push to my repository (visible to my collaborators, and with daily backups) when I have reached a point where I think it's worth that the collaborators get it (usually daily). Work on new features is done in local branches (very cheap with git), collaborators usually pull my master branch, and I pull theirs. Since there is no central repository, data exchange is less formal and easier. And (the killer argument for me): I have versioning on my local machine, without network connection (of course you can use CVS/RCS, but that does not make sense anymore given the new decentralized VC systems).

I do agree that CVS is dead. It was adequate, but it is no longer being supported.

SVN is still the most active Revision Control system out there. I think you can set up an account on sourceforge.net for free. I think their favorite system is SVN.

Submitting cave survey data to sourceforge.net is dangerous. Sourceforge is world-visible, and I shure don't want the local caving-hero (advertising his caving adventures on the net, without any awe or scientific interest) to know all the details about new discoveries which are visible in plans.

They might provide Trac too, which is a nice ticket/bug tracker which integrates with SVN.

Trac is nice, but I'm not shure how much we would need it for cave survey data (this is what we talk about, isn't it?). Using git, for example, you can publish your repository on any web server space (also password protected), or any shared area on your computer, and just send the URL to your peers. From there they pull your changes, and you can pull theirs from either their repositories, or form a centralized space such as github.com (same cautions as about sourceforge.net apply). Summary: o version control is good (mandatory) o decentralized version control is much better o backups (long term) are a must git (or hg, bzr) provide all of this Best, Martin

Carl, I don't know why it doesn't work, but it appears you have created a program to produce walls based on the LRUD. Nice idea! But you can achieve similar just be asking Therion to output the LRUD data in the output map, which is much easier than what you are doing and great for that initial visualisation of the survey data. Therion also accurately reflects the Left-Right values entered, so the cave walls follow the centreline at the correct distances (eg where the centreline zigzigs from left wall to right wall). Regards, - Ben Cooper

I have been working on a larger cave and storing all the survey data in my own program which exports to therion files. For a particular survey the scraps are not being drawn correctly, but drawing just the centerline from the survey data looks fine.

Posted here http://mbug.dyndns.org/example/ are two thconfig files, one with the scraps and one without and the generated PDF files. The shot B009-B010 for example looks fine in the just centerline export, but does not show up on the export from scraps (even though it has a scrap which looks correct).

Does anybody know why this would be happening? I do not see any errors from therion, even running it with the -d flag, and it appears to me that all the input data is formatted correctly.

Thanks,

Carl

_______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion

On 16.11.2009, at 21:07, Carl Magnuson wrote:

Thanks for the suggestion but I don't think it would work in my case - I simplified the data to show the problem I was having, but I am actually making a number of different wall types from the LRUD data and as I understand it Therion will only create regular walls from LRUD data.

What I don't understand is your scraps looked as directly created, without help of xtherion map editor. What was the reason? Therion will make walls from all lines with atribute -wall. You may use LRUD to generate the .xvi file (export map -o map_lrud.xvi) or to add splay points to sketched walls and therion will morf the sketches according the points, etc... m.

BTW, way you use the Czech language for exported maps? :) m.

I use english, but I took out all of my layout commands to make a simpler example. I haven't decided to learn Czech through Therion at least not yet :P Carl On Nov 16, 2009, at 4:08 PM, Martin Sluka wrote:

BTW, way you use the Czech language for exported maps? :)

m. _______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion

You are saying there is something odd Therion is doing with the calibration? I did try playing around with scale option to see if that helped (no luck) and I also tried scaling the line sizes to be shorter or longer (like 0 .5 1 .5 vs. 0 5 10 5) and the latter seemed to increase the distortion, but scaling it down even more didn't seem to have an impact. Carl On Nov 16, 2009, at 5:11 PM, Martin Sluka wrote:

There is something very strange with the calibration of scraps. Check the files I created in traditional therion way based on yours ones :)

m.

<Picture 1.png><Picture 2.png><Picture 3.png><Archive.zip>_______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion

Bruce If you have beginners, I personally would stick to one that does have a central record somewhere, if you want to support decentralised systems fine, but set it up in a way that the beginners can just log onto the 'central' record and have to 'commit' every change. I have now tried using SVN with at least 3 sets of caving data. Trying to get people to understand a simple update and commit routine is hard enough, without the decentralised options, that I also find confusing. I would only go down that route for expeditions where it is difficult/impossible to talk to the central. If you need it I have a document showing beginner windows users how to set up tortoiseSVN, but it is a few years only now, so the pictures are certainly not the correct ones Andrew

Martin Lüthi wrote:

Hi again

At Sun, 15 Nov 2009 12:49:46 -0700, Aaron Birenboim wrote:

...

...

For the purpose of tracking files and exchanging them with collegues, only decentralized VC makes sense (maybe with a central repository, but that is not important). CVS is dead, SVN is not very good for that purpose. Huh? That is the primary purpose of SVN, AFAIK.

SVN is great for centralized data repositories. I used to use it for several years for all my data, basically synchronizing laptop and desktop, and collaboration on projects. The major drawback (for me) is that you need a connection to the server with the central repository to commit changes.

This can be a good thing. Easier for one person to set up a server than many to establish peers.

After having switched to git (any distributed VC such as hg or bzr will do), I commit every non-trivial editing/work step locally, and push to my repository (visible to my collaborators, and with daily backups) when I have reached a point where I think it's worth that the collaborators get it (usually daily).

Yes. a drawback of SVN is the branching. I'm sure it is easier in GIT, but learning how to use it is tricky. The Suggested SVN method is to work in a branch, commit frequently, then merge back to trunk when you are ready to share. Agreed, this is a pain. Inferior to CVS. I'm glad to hear that GIT addresses this.

Work on new features is done in local branches (very cheap with git), collaborators usually pull my master branch, and I pull theirs.

Since there is no central repository, data exchange is less formal and easier. And (the killer argument for me): I have versioning on my local machine, without network connection (of course you can use CVS/RCS, but that does not make sense anymore given the new decentralized VC systems).

Yea. I often use RCS for local versioning. Then again, I usually have a network, and update repositories often (in branches).

...

I do agree that CVS is dead. It was adequate, but it is no longer being supported.

...

SVN is still the most active Revision Control system out there. I think you can set up an account on sourceforge.net for free. I think their favorite system is SVN.

Submitting cave survey data to sourceforge.net is dangerous. Sourceforge is world-visible, and I shure don't want the local caving-hero (advertising his caving adventures on the net, without any awe or scientific interest) to know all the details about new discoveries which are visible in plans.

I wasn't aware survey data was part of this repository. Perhaps I missed part of the conversation. I was thinking about the application source.

...

They might provide Trac too, which is a nice ticket/bug tracker which integrates with SVN.

Trac is nice, but I'm not shure how much we would need it for cave survey data (this is what we talk about, isn't it?).

Yea. for survey data, somebody would need to provide SVN over SSH.

Using git, for example, you can publish your repository on any web server space (also password protected), or any shared area on your computer, and just send the URL to your peers. From there they pull your changes, and you can pull theirs from either their repositories, or form a centralized space such as github.com (same cautions as about sourceforge.net apply).

Fair enough. With those requirements, perhaps getting people to learn GIT is worth the effort. aaron