tag:blogger.com,1999:blog-6555947.post4267282876518186831..comments2024-03-14T01:32:43.610-06:00Comments on The Geomblog: Papers and SVNSuresh Venkatasubramanianhttp://www.blogger.com/profile/15898357513326041822noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-6555947.post-60107005347431371282010-02-14T13:15:59.888-07:002010-02-14T13:15:59.888-07:00To all the folks pointing out that SVN has local a...To all the folks pointing out that SVN has local authentication methods: you are all right. However, our machines are managed by support staff, and I don't have direct control over the machines, so I only have access to svn via the method they provide (namely svn+ssh://Suresh Venkatasubramanianhttps://www.blogger.com/profile/15898357513326041822noreply@blogger.comtag:blogger.com,1999:blog-6555947.post-4685003106141350902010-02-14T13:11:34.657-07:002010-02-14T13:11:34.657-07:00SVN has its own authentication system. It was a li...SVN has its own authentication system. It was a little bit of hair pulling to learn to set it up the first time, but after that it has worked just fine. You should look into it.Arvind Narayananhttps://www.blogger.com/profile/02495762505427759752noreply@blogger.comtag:blogger.com,1999:blog-6555947.post-81713787698947702462010-02-13T09:12:26.032-07:002010-02-13T09:12:26.032-07:00Following on my comment above about "ssh"...Following on my comment above about "ssh", I realized that this is probably a better reference. <br /><br />http://svnbook.red-bean.com/en/1.4/svn.serverconfig.svnserve.html<br /><br />The issue of giving limited ssh access is discussed near the bottom.<br /><br />A.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6555947.post-65016777241529159932010-02-13T09:04:24.625-07:002010-02-13T09:04:24.625-07:00Hi Suresh,
Regarding svn + requiring login, you ...Hi Suresh, <br /><br />Regarding svn + requiring login, you may or may not be comfortable with it, but this is how I do it: my (remote) collaborators have ssh access into my account, but only for the purpose of using "svn". This is very easy to set up.<br /><br /><a rel="nofollow">http://subversion.apache.org/faq.html#ssh-authorized-keys-trick</a><br /><br />I am sure git probably does this better and I will switch to it eventually, but after convincing about 10+ collaborators/students to use svn, I am not about to go through that again any time soon.<br /><br />A.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6555947.post-53998805382163224942010-02-13T07:40:56.023-07:002010-02-13T07:40:56.023-07:00Did anyone try
http://projectlocker.com/
for wri...Did anyone try<br /><br />http://projectlocker.com/<br /><br />for writing papers? It is supposed to be free for up to 5 users.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6555947.post-2576503009421649142010-02-12T13:23:42.089-07:002010-02-12T13:23:42.089-07:00It's also possible to admin svn in such a way ...It's also possible to admin svn in such a way that security isn't tied to logins on the Unix server where it lives, but rather is hard-coded.<br /><br />Whenever I begin working with a new collaborator, I just manually add a new login to my svn's passwd file, and so home institution doesn't matter. This is not at all sophisticated, but for a svn server with O(10) users it's fine.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6555947.post-90183181954347482962010-02-12T11:31:24.407-07:002010-02-12T11:31:24.407-07:00A collaborator of mine (at a different institution...A collaborator of mine (at a different institution) set up an SVN structure for a paper we were working on. I asked about sending out email notices for updates and he argued that it was against the spirit of SVN that should encourage many easy small updates whenever you get a chance. <br /><br />I see his point to some degree, but in retrospect, I would have liked to known sooner when my coauthors made updates. I think a couple times this led to us both editing the same sections and someone needed to run a Merge.Jeff Phttps://www.blogger.com/profile/02817986846758586086noreply@blogger.comtag:blogger.com,1999:blog-6555947.post-70545396553013818412010-02-12T11:27:02.149-07:002010-02-12T11:27:02.149-07:00jelani: suppose I'm writing a paper with you. ...jelani: suppose I'm writing a paper with you. I can't give you access to my svn repo, because you'd need an account to access it (our system doesn't do svn over http). You can't get an account because you're not at Utah. <br /><br />that's the attraction of distributed version control.Suresh Venkatasubramanianhttps://www.blogger.com/profile/15898357513326041822noreply@blogger.comtag:blogger.com,1999:blog-6555947.post-18334841031327703962010-02-12T11:22:48.204-07:002010-02-12T11:22:48.204-07:00@Anonymous Note that I tend to use version control...@Anonymous Note that I tend to use version control even for just myself when I write papers - the big power isn't the communication aspect, it's the _versioning_ aspect. I don't have to worry about which version lives where or what I'm editing - since that's saved away in the Mercurial/SVN/whatever metadata.<br /><br />The ability to be able to just work ahead, deleting things with great abandon, and knowing that since I checked in earlier, everything I'm ripping out is still around, should I realize I need it, makes paperwriting and editing just SO much more structured, clean and enjoyable.<br /><br />(captcha: remakers)michiexilehttps://www.blogger.com/profile/00008302080954798496noreply@blogger.comtag:blogger.com,1999:blog-6555947.post-45705712181735055232010-02-12T11:20:30.303-07:002010-02-12T11:20:30.303-07:00I use Mercurial (hg) for my collaborative projects...I use Mercurial (hg) for my collaborative projects - with good results. It has the benefit, much like git, bazaar, darcs, and all the other happy players in the DVCS-world (distributed version control system) that you aren't required to rely on a joint server with common login for everyone - and indeed, for at least one project, we've been passing around Mercurial changesets by email to keep ourselves synchronized.<br /><br />It won't work for everyone: a few of the people I've interacted with have been strongly reluctant; but for those who try it, the ease to check changes, to merge changes (magically does the right thing most of the time!!) and the power of it as a communicative tool have been some of the major selling points.michiexilehttps://www.blogger.com/profile/00008302080954798496noreply@blogger.comtag:blogger.com,1999:blog-6555947.post-85624102145427764982010-02-12T11:09:07.494-07:002010-02-12T11:09:07.494-07:00SVN isn't ideal for collaborations across inst...<i>SVN isn't ideal for collaborations across institutions.</i><br /><br />SVN is all I've ever used, so I don't know any better. What about it don't you like that's better in git?Jelani Nelsonhttps://www.blogger.com/profile/00216475103758212305noreply@blogger.comtag:blogger.com,1999:blog-6555947.post-2013134488483906572010-02-12T10:51:38.443-07:002010-02-12T10:51:38.443-07:00This seems far too complicated. I don't want ...This seems far too complicated. I don't want to deal with checking out, checking in, having to maintain some special directory structure to avoid large downloads (I hope you were joking about this). Dropbox works a lot better for distributed paper collaborations, in my experience. It might be nice if there were better versioning inside Dropbox, though.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6555947.post-7486734391278591132010-02-12T10:36:00.257-07:002010-02-12T10:36:00.257-07:00I find Dropbox to be sufficient, and much easier, ...I find Dropbox to be sufficient, and much easier, for paper-writing. SVN has many features that make it useful for writing large software projects, but many of these issues do not come up in paper writing. If you want to simultaneously edit the same file at the same time SVN could be more helpful with its ability to merge, but generally in paper-writing there are fewer incidents of conflicts like this so it is not to bad to simply detect the conflict (which Dropbox does) and then use an external merge tool to fix it. Actually it is even better than SVN because you will detect the conflict immediately rather than after you both try to commit.<br /><br />In other situations it is much easier to use than SVN. It automatically syncs so you don't have to remember to do a check out or a commit. It is just client software to install and the servers are already set up by Dropbox.<br /><br />After going from email to SVN I would never go back to email, but after later going from SVN to Dropbox, I would never go back to SVN.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6555947.post-37524015934693874222010-02-12T10:26:06.302-07:002010-02-12T10:26:06.302-07:00You are right about git. Apparently it's is ev...You are right about git. Apparently it's is even better than SVN, especially if you don't have a server machine where to put the things. At the very worst anyone can have a local git repository, or you can use git on your own (this scenario is possible even with SVN). <br /><br />You can realize an on-line repository on any directory which is available on the web (without installing software on the remote machine). You just need to check who reads/writes on the directory.<br /><br />I use git, coupled with an editor which <br />has tools for managing diff files and versions, in case there are conflicting edits to merge.<br /><br />I also think that it is easier to setup than SVN (no server involved) for a very basic usage. This is good for reluctant/lazy workmates. :-DMassimohttps://www.blogger.com/profile/02407000877163973733noreply@blogger.com