[prev in list] [next in list] [prev in thread] [next in thread] 

List:       unison-users
Subject:    Re: [unison-users] "atomic" directories
From:       Andres Loeh <loeh () iai ! uni-bonn ! de>
Date:       2005-12-13 21:34:53
Message-ID: 20051213213452.GJ30133 () iai ! uni-bonn ! de
[Download RAW message or body]

> >Well, here's what I'd expect. If foo/bar is declared atomic, I'd  
> >expect
> >a conflict to be reported like this
> >
> >chgd dir <-?-> chgd dir   foo/bar  [] x
> >local        : changed dir     atomic contents modified on XXXX-XX- 
> >XX at XX:XX:XX  size XXXXX    rwxr-xr-x
> >remote       : changed dir     atomic contents modified on XXXX-XX- 
> >XX at XX:XX:XX  size XXXXX    rwxr-xr-x
> >
> >I.e., it'd just list the modification time of the most recently  
> >changed
> >file for each of the directories. If space would allow, it'd also  
> >be nice
> >to get a list of the changed files in each of the two dirs, but  
> >that's not
> >even necessary.
> >
> >I'd guess that "diff" and "merge" aren't available in this situation.
> 
> Just these two lines doesn't give the user much information about the  
> state of the world -- I doubt if it would be enough.  At least, you'd  
> need to be able to list the individual files and what happened to  
> them.  

Of course, that would be nice. But it wouldn't be required for me to
find the feature useful. Also, this situation only happens if someone
asks for this feature in the preferences, so these people should know
what they're doing ;)

> This would not be extremely complicated, but not trivial  
> either, since  it would involve some changes to the way things are  
> carried around in data structures and later formatted for display.
> 
> Another question for this presentation would be: What if the user  
> then chooses to override Unison's recommendation and asks for files  
> to be propagated one direction or the other?  (It's clear what should  
> happen, but again the implementation is not completely trivial.)

Yes. I already imagined that this might be some work.

> A different presentation could be to list all the individual files,  
> as now, but just mark each of them as a conflict, with a note to the  
> side explaining why.  This would require adding just this note field  
> to the current data structures.

Yeah, but it'd make it easy to accidentally resolve an atomic conflict
in a non-atomic way (by moving some files in one direction, and others
in the other). The link between the files should not be lost. I find
the other presentation preferable for this reason.

> My estimate would be that this would take one to two weeks' work for  
> someone that knows OCaml but not the Unison code base.

I'll have a look, but I can't promise anything. After all, I wanted
to write a serious OCaml program for quite some time now, but I haven't
really got any experience with OCaml so far ...

Cheers,
  Andres


------------------------ Yahoo! Groups Sponsor --------------------~--> 
Most low income homes are not online. Make a difference this holiday season!
http://us.click.yahoo.com/5UeCyC/BWHMAA/TtwFAA/26EolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/unison-users/

<*> To unsubscribe from this group, send an email to:
    unison-users-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 



[prev in list] [next in list] [prev in thread] [next in thread]