On 29 Feb 2008, at 17:07, Thomas Aylott - subtleGradient wrote:

Although I've been trying to move to Mercurial or Git for quite a while, I would most highly recommend Subversion for what you have in mind.

[snip]

I'd second all that. For most writing projects Subversion should be ideal. It only gets tricky if you want to do a load of branching and merging - and even then it's fairly straightforward if you follow the rules.

A caveat: most version control systems, Subversion included, are best at merging changes from multiple sources if those changes are confined to discreet lines. For code that's usually not a problem but with text someone might be tempted to reformat text to, e.g. pull a paragraph back into shape after edits. Because words are reflowed across multiple lines that makes the effective extent of the change much greater - and can result in commit conflicts which have to be resolved manually.

That's less of a problem if different committers are working on different parts of the document and also if everyone commits pretty regularly rather than attempting to commit large sets of edits at once.

Am 29.02.2008 um 18:32 schrieb Gerd Knops:

On Feb 29, 2008, at 11:18 AM, Andy Armstrong wrote:

...

On 29 Feb 2008, at 17:07, Thomas Aylott - subtleGradient wrote:

...

Although I've been trying to move to Mercurial or Git for quite a while, I would most highly recommend Subversion for what you have in mind.

Not sure I agree. With subversion, unless you have access to the server, you can't do version control. That precludes offline working.

For that very reason I have been using darcs. It allows me to do version control locally, and push the changes out to a server whenever I want/can.

Now darcs has some rough edges and I would not necessarily recommend it, though it works fine for me. Like others I have not yet found the time to check out Mercurial or Git, which I think offer similar features for offline work.

we are using mercurial for our php framework. it works great but is a little harder to understand in the first place. being able to do local version control is a big win, i think. we also think about moving all our projects from svn to mercurial around next summer... svn is great. but mercurial is better with merging things, which we do from time to time.

On Mar 1, 2008, at 6:05 AM, Christoph Held wrote:

How linear is a series of versions? For actual writing (as opposed to coding perhaps) it would be absolute bliss to be able to decide that you would want to return to the wording of the discussion three versions previously *without* discarding the work you have done meanwhile.

Is that possible and how do the usual suspects differ with respect to this?

Well, once everything is in a repository, then (in principle) anything can be reverted. However, trawling back through the history for small changes that were committed together with many others can be difficult. And, at least with Subversion, you can only automatically revert an entire changeset's changes for a given file (reverting only part of a changeset for a given file requires a bit of manual effort). If I am wrong on this, please correct me.

Two things can help with this, especially on writing projects. First, you can commit frequently, and organize each commit so that it is making a single, well-defined change (e.g., "revise abstract to meet word limit" or "refer to this SNP by a different name"). This will make it easier to browse through the change log and revert specific changes. Second, if I'm struggling with the wording for a particular paragraph, say, I'll usually leave the original version as a comment in the file, adjacent to the newly proposed version. This makes it easy to see what the changes were, and to combine elements of both versions at some point in the future. Of course, you could take this reasoning to the extreme, and just preserve all changes in one, large text file. Clearly, that would not be helpful; moreover, this is what your VCS should be doing for you. Thus, you probably will want to use this technique sparingly.

-- Phil

Tim, I am inclined to agree with you about Git. Nonetheless, if Christoph is working with colleagues who need to be persuaded to use version control at all, Git might not be the best choice. And btw, the git-bundle rocks! Nice work. Best, Mark

On Feb 29 2008, at 20:12, Tim Harper wrote:

I'll chime and say that switching from subversion to git has made me dread working with subversion.

Plus, not to toot my own horn, but I REALLY like working with the git textmate bundle: http://gitorious.org/projects/git-tmbundle

Tim

On Feb 29, 2008, at 10:42 AM, Mike M wrote:

...

On Fri, Feb 29, 2008 at 7:37 AM, Christoph Held <prion67@googlemail.com

...

wrote:

Hi

rather than piggybacking on my other thread, I wanted to ask another question, namely which version control system to take for collaborative writing projects.

Emacs rules! (oh, sorry wrong topic, but expect the same results)

I have used subversion for several years, and it works. However, I think it can be overkill for smaller projects. For my personal use I have been using Bazaar (bzr) for about six months and really like it. It is simple to set up, works cross-platform, and is decentralized (but can be used with a central server).

Mike

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

That's been in the pipeline. But, the current framework for the bundle has reached it's capacity and is becoming burdensome to further develop and do what I want with it. So before I blaze ahead, I've decided to tackle this important issue. (Software that is easy to write generally depends to be easy to use)

I just committed the beginnings of mini-MVC framework for the bundle, which will open up a lot of new possibilities for development.

Warmly, Tim

On Mar 1, 2008, at 4:52 AM, Christoph Held wrote:

You are getting good press, too.

Is there a way of integrating a graphical diff tool at some stage before or after the merge using git (and your bundle)?

On Fri, Feb 29, 2008 at 9:12 PM, Tim Harper timcharper@gmail.com wrote: I'll chime and say that switching from subversion to git has made me dread working with subversion.

Plus, not to toot my own horn, but I REALLY like working with the git textmate bundle: http://gitorious.org/projects/git-tmbundle

Tim

On Feb 29, 2008, at 10:42 AM, Mike M wrote:

...

On Fri, Feb 29, 2008 at 7:37 AM, Christoph Held <prion67@googlemail.com

...

wrote:

Hi

rather than piggybacking on my other thread, I wanted to ask another question, namely which version control system to take for collaborative writing projects.

Emacs rules! (oh, sorry wrong topic, but expect the same results)

I have used subversion for several years, and it works. However, I think it can be overkill for smaller projects. For my personal use I have been using Bazaar (bzr) for about six months and really like it. It is simple to set up, works cross-platform, and is decentralized (but can be used with a central server).

Mike

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

I've installed git on windows using mingw distro. It comes with an installer and everything, and it does a really great job! The git-gui has a bit of a problem (I can't create commits from it), but the console works perfectly well as far as I can tell.

It is a preview release, so stability is not guaranteed. You'd want to do your own experimentation with it, first.

http://code.google.com/p/msysgit/

As Mark said, subversion may just fit your needs. For what we've been doing (we branch like crazy), git has been superb. I haven't had any motivation to try Mercurial or bazaar yet.

Tim

On Feb 29, 2008, at 1:15 PM, Mark Eli Kalderon wrote:

My two cents:

The most important thing is that you use version control. I have been a happy Subversion user for three years now, but eventually found myself frustrated with its merging facilities and am now learning Git (since it allows you to cherry pick the changes you want to merge).

For your purposes, however, I would not recommend Git (not quite cross platform since it lacks a Windows implementation, I think) and its UI is not as nice as some alternatives.

I think you might try Mercurial or Bazaar.

There are advantages to using a distributed version control system as opposed to a centralized one like Subversion, but really any of Subversion, Mercurial, or Bazaar would suit your needs.

They are all easy to install. Since you don't have Leopard yet (which has Subversion preinstalled) you can use Martin Ott's OS X binary.[1] The first two chapters of the Subversion book (available free online) should be enough to get you working with subversion in an afternoon.[2]

There are binaries for OS X and Windows for Mercurial (I think that Mercurial also comes with keychain support on OS X).[3] Like Subversion, it comes with a nice manual.[4]

Finally, Bazaar also comes with binaries for OS X and Windows.[5] And also has extensive documentation.[6]

You might be well served by downloading them all, spend a weekend playing with a couple toy repositories and think about how they might work best with your envisioned work flow. (Bazaar seems particularly flexible in this regard.)

Glad to hear that you are seriously considering version control. Good luck.

All the best, Mark

[1] http://homepage.mac.com/martinott/ [2] http://svnbook.red-bean.com/ [3] http://mercurial.berkwood.com/ [4] http://hgbook.red-bean.com/ [5] http://bazaar-vcs.org/Download [6] http://bazaar-vcs.org/Documentation

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

Many thanks everyone. Consensus seems to be - there is no consensus (Yay, emacs rules :-) ) Much seems to depend upon what you want to do with whatever VCS you end up using. Since I am no programmer, much of the power of the various systems may be wasted on me, yet some tiny feature that seems unimportant in the context of maintaining code may make a big difference to what *I* want it to do.

Mark, what made you choose git over the other DVCS for actual writing? What do you mean by cherry picking? Do Mercurial, SVN and bazaar give you less control over what changes willl be kept during a merge? This would indeed be an important difference as merging writings of coauthors will be daily life rather than the exception.

For the moment distributed sounds good to me, simply because I tend to work most efficiently when I am isolated from phone, lab etc. Being able to keep versioning during that time, too, would be a big plus in my book.

Christoph

On Fri, Feb 29, 2008 at 9:15 PM, Mark Eli Kalderon eli@markelikalderon.com wrote:

My two cents:

The most important thing is that you use version control. I have been a happy Subversion user for three years now, but eventually found myself frustrated with its merging facilities and am now learning Git (since it allows you to cherry pick the changes you want to merge).

For your purposes, however, I would not recommend Git (not quite cross platform since it lacks a Windows implementation, I think) and its UI is not as nice as some alternatives.

I think you might try Mercurial or Bazaar.

There are advantages to using a distributed version control system as opposed to a centralized one like Subversion, but really any of Subversion, Mercurial, or Bazaar would suit your needs.

They are all easy to install. Since you don't have Leopard yet (which has Subversion preinstalled) you can use Martin Ott's OS X binary.[1] The first two chapters of the Subversion book (available free online) should be enough to get you working with subversion in an afternoon.[2]

There are binaries for OS X and Windows for Mercurial (I think that Mercurial also comes with keychain support on OS X).[3] Like Subversion, it comes with a nice manual.[4]

Finally, Bazaar also comes with binaries for OS X and Windows.[5] And also has extensive documentation.[6]

You might be well served by downloading them all, spend a weekend playing with a couple toy repositories and think about how they might work best with your envisioned work flow. (Bazaar seems particularly flexible in this regard.)

Glad to hear that you are seriously considering version control. Good luck.

All the best, Mark

[1] http://homepage.mac.com/martinott/ [2] http://svnbook.red-bean.com/ [3] http://mercurial.berkwood.com/ [4] http://hgbook.red-bean.com/ [5] http://bazaar-vcs.org/Download [6] http://bazaar-vcs.org/Documentation

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

On Mar 1, 2008, at 6:20 AM, Christoph Held wrote:

I am very serious about starting using version control for academic writing. And it is not as if you had nothing to do with it. When doing some reading along these lines I stumbled about some of your articles in Practex journal. Although you advocated using Subversion back then, the message for me was to use any kind of versioning system at all.

The last time doing a manual merge of three documents from different authors was an absolute nightmare and took a lot of time. Even if I were using version control for myself only, I'd imagine I could still put it to good use by feeding it my coauthors works after converting them to plain text myself. This is actually one of my reasons I am favouring MultiMarkdown over pure Latex at the moment as it is human readable and easy to convert to *.rtf or eben *.doc format.

I use SVN for all my coding projects, but also for academic writing. WRT latter, if I am the sole author, then I write in either LaTeX or reStructuredText, and use SVN pretty much exactly like I would for a coding project. In cases where I am not the sole author (which happens to be most of my work at the moment), I have found that the critical distinctions are (1) are my coauthors willing to work with text files (e.g., LaTeX, reST, or some other markup), and (2) are they willing and/or interested in learning Subversion? This yields 4 cases:

(i) If your coauthors are willing to work with text files, then everything is still pretty straightforward. Even if they don't access the repository themselves (or perhaps just have read-only access), you can still distribute copies of exactly what's in the repository to them, and handle the files you get back from them using standard diff and merge tools.

(ii) Unfortunately, it can be difficult unless you are in a mathematical or computer science-related field to find coauthors who are comfortable working with text files. Even if you're not asking them to use LaTeX (i.e., you use some kind of simplified markup) and are only asking them to enter their revisions into a master text file that you have already set up, many people will still try to do this in Word, and then want to use "track changes" to make their edits and comments. If your coauthors insist on using Word to make their edits and comments, then I've found the following approach works pretty well. I still maintain the master document in LateX or reST (stored in the repository), but then translate it into Word for distribution to my coauthors (e.g., using LaTeX -> latex2rtf -> RTF -> open in Word and save, but there are many other options for doing this). When I get back comments, I check out a copy of the project at the revision from which it was distributed, and then make the changes manually from each coauthor. If you use separate checkouts for each coauthor, then you can use SVN's built-in features for resolving conflicts between their different sets of changes, rather than having to do it manually. In addition, when I do this, I always use Word's "compare documents" feature to compare what they send me to the document I distributed to them. That way, even if they forget to use "track changes" (or use it inconsistently), I'm sure not to miss any changes.

You can, if you want, check in the Word document(s) you distribute and the ones you get back from your coauthors (with their changes), just for completeness sake. However, this will begin to fill up your repository with a lot of binary junk, and you can't use standard diff and merge tools with these files. Moreover, since MS Office files are automatically modified every time you open them (even if you don't save any changes), they're lousy for strict tracking of changes (e.g., using diff or checksums).

(iii) While I've had little luck getting people who are used to Word to use text files, I have had some luck getting non-technical people to learn how to use Subversion. This is because it is easy-to-use (at least for most standard operations), well-documented, and tools like TortoiseSVN make it very easy for Windows users to pick up. If your coauthors want to do this -- even if they are using Word -- it can still be helpful, because it eliminates your having to serve as the middle-man for exchanging files and provides you with an automatic log of all versions. If you do this, one strategy is to create a "Word" branch of your project, where your coauthors can checkout the latest Word version and checkin their changes. You can then occasionally merge the changes from this branch onto the trunk and update the branch with your own changes (from the trunk), as necessary. In fact, as long as you're careful not to copy files between the branch and trunk, this also makes it easy to purge the repository of all the Word files, once the paper has been published.

(iv) If your coauthors use LaTeX (or some other text-based markup) *and* know or are willing to learn SVN, then you're in heaven. Everything works just like a software project. Believe it or not, this has occasionally happened to me.

Just a few of my own experiences -- YMMV.

-- Phil

P.S. IMHO, the simplicity of Subversion, its excellent documentation, and the existence of graphical clients like TortoiseSVN (for those coauthors who aren't comfortable working at the command line) should not be overlooked, especially for projects like academic writing (or any writing, for that matter). In addition, if you are going to essentially have your own, private repository, then the benefits of distributed version control become much less important, if at all (i.e., you can just keep a copy of your entire repository on your laptop).

On Fri, Feb 29, 2008 at 7:41 PM, Fred B fredb7@gmail.com wrote:

On 29 Feb 2008, at 17:37, Christoph Held wrote:

...

what would you choose?

I'd totally go with a distributed VCS. The possibility to work offline is a good reason enough, IMHO.

After quickly trying almost every VCS, the one I picked first is Mercurial and it was a blessing compared to svn. With all the buzz git got lately, I decided to try it for real on a project. To make it really short: I think git can be more powerful, but is harder to learn, and after 15 days i still scratch my head on some edge cases.

So I'd say Mercurial, Git, Darcs... See the one that suits you best.

I've used all of Subversion, Git and Mercurial. Of the DVCSes, hg is initially easier to grasp than git and presents a friendlier face. OTOH, some workflows which are easy in git are much more difficult in hg. (For example, IMO, maintaining a patch series with git rebase is much more straightforward than dealing with hgq.) I currently use git -- once you understand the index it's like crack.

Anyway, I think your first decision is Subversion vs a DVCS. If you decide on a DVCS, you then need to choose which one.

One thing to keep in mind is that whatever decision you make isn't totally cast in stone. It's pretty straight-forward to convert from Subversion to a DVCS (well, at least to git or hg, and I'd imagine to bzr as well), and you can also convert between the DVCSs with varying degrees of ease.

Another option is using git as an svn client. You can setup an svn repo, let most folks use the normal svn clients, and for anyone who wants the ability of offline commits, just let those folks use git's svn integration.

j.