I've not been a Facebook user, but I was invited to join Google+, so I set up a picture and am waiting to see what it's all about. I'm afraid that for the most part I'm not so interested in a wall where people tell me what's going on with them, nor do I see the point in writing to groups of people I know to update them on my life this way, but perhaps over time I'll be converted to this way of socializing. Until then, I guess I'll keep writing blog posts if I feel I have something to say (which, admittedly, has been less often these days).
600+ abstracts submitted to SODA. I wonder what the over/under is on how many will actually be papers a week from now. I'm expecting about a 10% drop, but wouldn't even be surprised to see it go down to 500 or so. That suggests about a 25+% acceptance rate. I'm not sure what message there is to take out of that. But given that 500 seems to be the total of accepted papers for SODA, STOC, FOCS, ESA, ICALP, and maybe another conference or two after that (SPAA, PODC?), it seems like theory is (still) producing too many papers, or has too few venues to publish them in. Larger conferences, or perhaps a large clearing-house conference, anyone? (Would SODA be that much different if it accepted, say, 250 papers? Discuss.)
While I think svn is great for collaborations, I've really found the merging functionality has negligible utility. I'm a novice user, but it seems whenever there's a conflict, the fastest way to deal with it is still to pick a winner, diff for differences, and glue together by hand. I think the bottleneck is when there's a conflict, I want to work out differences with my colleague, and the whole point is that we're working at different times and places. So the benefit of working separately seamlessly gets lost.
I still think everyone should be reading Claire's blog, which covers a really nice mix of topics, many of which could potentially lead to interesting community discussions.
Subscribe to:
Post Comments (Atom)
11 comments:
svn is so 10 years ago :-) try hg or git. they're vastly superior for handling conflicts. here's a link to mercurial merging: http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html, and git: http://www.kernel.org/pub/software/scm/git/docs/git-merge.html
As a svn user, I suggest that you get a good client for it. A good interface to the merge makes it much easier. Still, I find that I rarely need to use it because most of the merging is automatic if you edit different parts of the document.
BTW, everything I do is either in my svn repository or someone else's.
Merging text requires a bit of thought in organizing the paper source code in the first place. A typical setup that seems to work well is to put each section into a separate file, and ideally putting sentences in a paragraph on separate lines.
If you have merge conflicts, usually that means you have poor SVN habits.
1. You should be making small commits, and committing frequently (don't save up tons of changes and then commit).
2. You should be doing a "svn update" before making any edit.
3. Lines should be short. You shouldn't have the entire paragraph on line. Insert line breaks after about 72 characters or so, so it fits on a 80-column screen. (SVN's diff algorithm is line-based, so scrunching everything on one line can cause unnecessary merge conflicts.)
4. You should never re-flow or re-justify text that you didn't change. (SVN's diff algorithm is line-based, so this looks like a change to SVN and can cause gratuitous merge conflicts.)
My experience is that if you follow these rules, then merge conflicts are rare.
Line-based diffs are really annoying and often cause me annoyance in working with co-authors. I want to know what has changed between versions and it is a pain to include line-breaking changes.
Defaults in winedit and some other editing environments are for some form of line-wrap which creates new line breaks (in winedit it must be deselected in multiple places to completely eliminate it).
I'll vote for 500 submissions when the dust settles.
The inability of these versioning tools to deal with line breaks ruins them for me. I want a tool that just works, not one that I have to work around.
From what comments seem to say, I should spend an afternoon getting an svn tutorial and getting past my "novice" status.
Also, I do find that merging issues are rare -- precisely because (as commenters point out) we usually structure the file in section-sized pieces and avoid clobbering each other. On rare occasions, though, two people have REALLY worked on a file at the same time; at that point, perhaps it's just an unpleasant exercise no matter what tool you're using.
Thanks for the plug Mike!
Any gossip yet on the number of abstracts that became actual submitted papers?
A different slant on Dan Spielman's earlier comment:
Maverick Woo suggested at Version control for collaboration (with word-level diffs)? using wdiff for word-based edit conflict detection in svn, replacing the default line-based conflict detection. This might take you a step closer to a reasonable merging strategy for resolving conflicts.
Post a Comment