Hacker News Reader

Comment by rcthompson | Hacker News Reader

From my perspective, the main Dropbox feature that all the "thin layer on top of VCS" clones miss is the conflict-resolution behavior of Dropbox. If both you and someone else edit a file called "stuff.txt" at the same time, you'll end up with two files: "stuff.txt" and "stuff.txt (other guy's version)". Neither person's changes are blown away, there's never any merge conflicts, and the history remains linear.

I'll have to see if Gitdocs does anything like that.

View on HN

Oo. Great idea. I'll add that.

It's not as simple as it sounds. What if there's already a file called "stuff.txt (other guy's version)"? There's lots and lots of edge cases. You basically need a function that can always return an appropriate but not-already-existing filename.

I think graceful file conflict resolution will be an essential part of gitdocs and we will work to handle these edge cases as best as we can. Thanks for bringing it up.

You might want to look at this bit: https://github.com/hbons/SparkleShare/blob/master/SparkleLib...

It tries to copy the Dropbox conflict behaviour.

Interesting. I'll have to try it out again.

Although, if I'm reading this correctly, the logic isn't quite right. It uses the timestamp of the time when the conflict is detected, when it should really use the conflicted file's last-modified time, or maybe the timestamp of the conflicting commit.

"stuff.txt (sha1)" works. User-friendliness of it depends of user base (and might actually be a feature as it traces back to the exact history point)

This requires another "merge strategy" in git terminology.

http://www.cs.potsdam.edu/cgi-bin/man/man2html?1+git-merge#l...

Reply on news.ycombinator.com