3 ms·

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 an

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.

joshbuddy 15y ago
Oo. Great idea. I'll add that.
- rcthompson 15y ago
  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.
  - nesquena 15y ago
    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.
    - hbons 15y ago
      You might want to look at this bit: https://github.com/hbons/SparkleShare/blob/master/SparkleLib/Git/SparkleRepoGit.cs#L293 https://github.com/hbons/SparkleShare/blob/master/SparkleLib... It tries to copy the Dropbox conflict behaviour.
      - rcthompson 15y ago
        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.
  - lloeki 15y ago
    "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)
beza1e1 15y ago
This requires another "merge strategy" in git terminology. http://www.cs.potsdam.edu/cgi-bin/man/man2html?1+git-merge#lbAL http://www.cs.potsdam.edu/cgi-bin/man/man2html?1+git-merge#l...

joshbuddy 15y ago

Oo. Great idea. I'll add that.

rcthompson 15y ago
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.
- nesquena 15y ago
  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.
  - hbons 15y ago
    You might want to look at this bit: https://github.com/hbons/SparkleShare/blob/master/SparkleLib/Git/SparkleRepoGit.cs#L293 https://github.com/hbons/SparkleShare/blob/master/SparkleLib... It tries to copy the Dropbox conflict behaviour.
    - rcthompson 15y ago
      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.
- lloeki 15y ago
  "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)

beza1e1 15y ago

This requires another "merge strategy" in git terminology. http://www.cs.potsdam.edu/cgi-bin/man/man2html?1+git-merge#lbAL http://www.cs.potsdam.edu/cgi-bin/man/man2html?1+git-merge#l...