From teller at csail.mit.edu  Wed Mar  7 09:29:22 2007
From: teller at csail.mit.edu (Seth Teller)
Date: Wed, 07 Mar 2007 09:29:22 -0500
Subject: [Unison-hackers] unison major and minor version numbers (need >
	2.17?)
Message-ID: <45EECC42.7020309@csail.mit.edu>


hello,

i'm writing with a question about unison version numbers,
one which is not (fully) addressed by the FAQ.

we are running 2.17.1 at MIT -- on personal laptops which
are administered privately, and on a lab-shared AFS server,
which is administered centrally.  i am experiencing fatal
errors when trying to initialize unison from two large
directory trees that differ slightly.  running unison with
-debug all and -debug verbose gives me no better clue as
to what is going wrong.  i have been advised to upgrade to
a newer unison.

i found compiled windows+GTK 2.27.1 binaries posted (see
below), but our sysadmins want the source code themselves.
i understand that one can do an svn checkout and build, and
it seems that the minor version number is auto-incremented.
but where did the major number 27 come from?  is that
something that is propagated by some core set of developers?
and if so, can someone point me to "blessed" 2.27.X source?

thanks,

seth teller

> Background thread:

noah,

it seems that only the first two version components are
compared (see below).  i'll find out what the deal is
with 2.17 vs. 2.27.

thanks,

seth

 From the unison FAQ:
I get something like 'Fatal error: Received unexpected header from the
server: expected "Unison 2.13\n" but received "Unison
2.17\n\000\000\000\000", which differs at "Unison 2.17".'

The versions of unison running on the server and the client must
match. (Specifically, the first two components of the version number
must match exactly: versions 2.24.6 and 2.24.10 will happily talk to
each other, but 2.17.3 and 2.24.10 will not). If all you need is the
textual user interface, compiling binaries for most distributions is
straighforward.

----- Forwarded message from alan.schmitt at polytechnique.org -----
      Date: Wed, 7 Mar 2007 08:12:02 +0100
      From: Alan Schmitt <alan.schmitt at polytechnique.org>
Reply-To: Alan Schmitt <alan.schmitt at polytechnique.org>
   Subject: Re: unison 2.27.1
        To: Seth Teller <teller at csail.mit.edu>

On 6 mars 07, at 23:37, Seth Teller wrote:

[Hide Quoted Text]
> hello --
>
> at
>
> http://alan.petitepomme.net/projets/unison/assets/Unison-2.27.1- Gtk.zip
>
> you have posted a compiled version of unison.  can you
> point me to the source repository from which you
> compiled it?  also, how did you generate the version
> number 2.27.1 -- was it associated with the source
> version, or did you assign it yourself?

The version number is generated automatically, and I think it was
compiled from the current source in SVN (I'm not the one who
generated this version).

Best,

Alan


----- End forwarded message -----


Quoting Noah Meyerhans via RT <help at csail.mit.edu>:

[Hide Quoted Text]
> On Tue, Mar 06, 2007 at 03:10:48PM -0500, Seth Teller via RT wrote:
>> i found a built 2.271.1 GTK version at
>>
>>    http://alan.petitepomme.net/projets/unison/index.html
>
> Which doesn't necessarily help.  We really need the source.  That site
> only has binaries for OS X and Windows.
>
> It seems like everybody who's ever released a pre-compiled binary has
> changed the version string.  Given how strict unison is about version
> matches, this is a real problem.  Since the most recent version of
> unison, as released by the actual unison developers, is 2.17.1, I
> wouldn't recommend that you use anything other than that, nor would I
> be comfortable installing anything else universally in CSAIL.
>
> Since there don't seem to be any pre-compiled versions of 2.27.1 for
> Linux, nor does the source code seem to exist, I'm not sure there's
> much we can do.
>
> noah
>
> --
> Noah Meyerhans                         System Administrator
> MIT Computer Science and Artificial Intelligence Laboratory
>
>
>
>
> You may also check your case on the web at:
> https://tig.csail.mit.edu/rt/Ticket/Display.html?id=26105
> (NOTE: access to this URL requires CSAIL web client certificate)
>


From teller at csail.mit.edu  Wed Mar  7 10:05:06 2007
From: teller at csail.mit.edu (Seth Teller)
Date: Wed, 07 Mar 2007 10:05:06 -0500
Subject: [Unison-hackers] unison major and minor version numbers (need >
	2.17?)
Message-ID: <45EED4A2.4000209@csail.mit.edu>


hello,

in case it's easier to just solve my original problem:
the output of unison -debug all is excerpted below up
to the point of

   Fatal error: Internal error: New archives are not identical.

does anyone know why this is occurring and how to fix it?

the usage scenario is that i have two laptops A and B with
slightly different directory trees.  i sync A to a common,
initially empty archive.  i then attempt to sync B to that
same archive.  the fatal error below issues, repeatably.

thanks,

seth



[remote_emit] Remaining tokens: 00\000\000\015\000\000...' 35 bytes
[server: remote_emit] Received the write permission
[server: remote_emit] Received write token (1)
[remote_emit] Restarting readeren
[remote_emit] Waiting for next message
[server: remote_emit] Waiting for next message
[server: update] Saving archive in 
/afs/csail.mit.edu/u/s/seth/.unison/sce67c05688562d423b0f0ff094369de99
[server: remote_emit] Sending result (id: 15)
[server: remote_emit] send [prepareCommit-res] 
'\132\149\166\190\000\000\000\006\000\000...' 26 bytes
[server: remote_emit] send [rsp] 
'\132\149\166\190\000\000\000\001\000\000...' 21 bytes
[server: remote_emit] Remaining tokens: 0
[server: remote_emit] Sending write token
[server: remote_emit] Message received (id: 16) (tokens: 1)
[server: remote_emit] receive 'rsp\132\149\166\190\000\000\000...' 38 
bytes[remote_emit] Message received (id: 16) (toke
ns: 1)
[remote_emit] receive 'rsp???+\000\000\000...' 24 bytes
[server: remote_emit] receive 'unlockArch...' 76 bytes
[server: remote_emit] Waiting for next message
[server: remote_emit] Received the write permission
[server: remote_emit] Received write token (1)<
 >[server: remote_emit] Waiting for next message!
[server: remote_emit] Sending result (id: 16)
[server: remote_emit] send [unlockArchive-res] 
'\132\149\166\190\000\000\000\001\000\000...' 21 bytes
[server: remote_emit] send [rsp] 
'\132\149\166\190\000\000\000\001\000\000...' 21 bytes
[server: remote_emit] Remaining tokens: 0?+\000\000\000&\000\000...' 58 
bytes
[server: remote_emit] Sending write token0\013\000\000...' 33 bytes
<>!<>![server: remote_emit] Message received (id: 17) (tokens: 1)
[server: remote_emit] receive 'rsp\132\149\166\190\000\000\000...' 36 bytes
[server: remote_emit] receive 'dumpArchiv...' 74 bytes
[server: remote_emit] Waiting for next message[remote_emit] Message 
received (id: 17) (tokens: 1)
[server: remote_emit] Received the write permissionytes
[server: remote_emit] Received write token (1)d 
Settings\seth\Desktop\unison\unison.dump'
[server: remote_emit] Waiting for next message
[server: update] Dumping archive into 
`/afs/csail.mit.edu/u/s/seth/unison.dump'
[server: remote_emit] Sending result (id: 17)
[server: remote_emit] send [dumpArchive-res] 
'\132\149\166\190\000\000\000\001\000\000...' 21 bytes
[server: remote_emit] send [rsp] 
'\132\149\166\190\000\000\000\001\000\000...' 21 bytes identical.
[server: remote_emit] Remaining tokens: 0Unison again to bring them up 
to date.
[server: remote_emit] Sending write token
Fatal error: Internal error: New archives are not identical.
C:\Documents and Settings\seth\Desktop>REM  > "C:\Documents and 
Settings\seth\Desktop\unison.txt" &

C:\Documents and Settings\seth\Desktop>REM tail -f "C:\Documents and 
Settings\seth\Desktop\unison.txt"

C:\Documents and Settings\seth\Desktop>REM wait until ctrl-C or window 
is closed

C:\Documents and Settings\seth\Desktop>pause
Press any key to continue . . . [server: remote] Connection closed by 
the client

From bcpierce at cis.upenn.edu  Wed Mar  7 10:15:38 2007
From: bcpierce at cis.upenn.edu (Benjamin Pierce)
Date: Wed, 7 Mar 2007 10:15:38 -0500
Subject: [Unison-hackers] unison major and minor version numbers (need >
	2.17?)
In-Reply-To: <45EECC42.7020309@csail.mit.edu>
References: <45EECC42.7020309@csail.mit.edu>
Message-ID: <BAFFFB74-5E48-4188-BDC6-EF2853DE90A1@cis.upenn.edu>

Hi Seth,

Here's how Unison's version numbers work: The "2" at the beginning is  
more or less a constant.  The middle number tracks changes to the  
communication protocol: it gets incremented whenever something  
changes that could cause confusion if client and server were running  
different versions.  The last number is incremented automatically on  
each svn checkin.

Version 2.27 is still officially an internal developer version (so  
the source code is only available direct from svn), but it is very  
close to a new stable release version -- there are just a couple more  
rough edges, which I hope to polish off in the next couple of days.

Regards,

     - Benjamin


On Mar 7, 2007, at 9:29 AM, Seth Teller wrote:

>
> hello,
>
> i'm writing with a question about unison version numbers,
> one which is not (fully) addressed by the FAQ.
>
> we are running 2.17.1 at MIT -- on personal laptops which
> are administered privately, and on a lab-shared AFS server,
> which is administered centrally.  i am experiencing fatal
> errors when trying to initialize unison from two large
> directory trees that differ slightly.  running unison with
> -debug all and -debug verbose gives me no better clue as
> to what is going wrong.  i have been advised to upgrade to
> a newer unison.
>
> i found compiled windows+GTK 2.27.1 binaries posted (see
> below), but our sysadmins want the source code themselves.
> i understand that one can do an svn checkout and build, and
> it seems that the minor version number is auto-incremented.
> but where did the major number 27 come from?  is that
> something that is propagated by some core set of developers?
> and if so, can someone point me to "blessed" 2.27.X source?
>
> thanks,
>
> seth teller
>
>> Background thread:
>
> noah,
>
> it seems that only the first two version components are
> compared (see below).  i'll find out what the deal is
> with 2.17 vs. 2.27.
>
> thanks,
>
> seth
>
>  From the unison FAQ:
> I get something like 'Fatal error: Received unexpected header from the
> server: expected "Unison 2.13\n" but received "Unison
> 2.17\n\000\000\000\000", which differs at "Unison 2.17".'
>
> The versions of unison running on the server and the client must
> match. (Specifically, the first two components of the version number
> must match exactly: versions 2.24.6 and 2.24.10 will happily talk to
> each other, but 2.17.3 and 2.24.10 will not). If all you need is the
> textual user interface, compiling binaries for most distributions is
> straighforward.
>
> ----- Forwarded message from alan.schmitt at polytechnique.org -----
>       Date: Wed, 7 Mar 2007 08:12:02 +0100
>       From: Alan Schmitt <alan.schmitt at polytechnique.org>
> Reply-To: Alan Schmitt <alan.schmitt at polytechnique.org>
>    Subject: Re: unison 2.27.1
>         To: Seth Teller <teller at csail.mit.edu>
>
> On 6 mars 07, at 23:37, Seth Teller wrote:
>
> [Hide Quoted Text]
>> hello --
>>
>> at
>>
>> http://alan.petitepomme.net/projets/unison/assets/Unison-2.27.1-  
>> Gtk.zip
>>
>> you have posted a compiled version of unison.  can you
>> point me to the source repository from which you
>> compiled it?  also, how did you generate the version
>> number 2.27.1 -- was it associated with the source
>> version, or did you assign it yourself?
>
> The version number is generated automatically, and I think it was
> compiled from the current source in SVN (I'm not the one who
> generated this version).
>
> Best,
>
> Alan
>
>
> ----- End forwarded message -----
>
>
> Quoting Noah Meyerhans via RT <help at csail.mit.edu>:
>
> [Hide Quoted Text]
>> On Tue, Mar 06, 2007 at 03:10:48PM -0500, Seth Teller via RT wrote:
>>> i found a built 2.271.1 GTK version at
>>>
>>>    http://alan.petitepomme.net/projets/unison/index.html
>>
>> Which doesn't necessarily help.  We really need the source.  That  
>> site
>> only has binaries for OS X and Windows.
>>
>> It seems like everybody who's ever released a pre-compiled binary has
>> changed the version string.  Given how strict unison is about version
>> matches, this is a real problem.  Since the most recent version of
>> unison, as released by the actual unison developers, is 2.17.1, I
>> wouldn't recommend that you use anything other than that, nor would I
>> be comfortable installing anything else universally in CSAIL.
>>
>> Since there don't seem to be any pre-compiled versions of 2.27.1 for
>> Linux, nor does the source code seem to exist, I'm not sure there's
>> much we can do.
>>
>> noah
>>
>> --
>> Noah Meyerhans                         System Administrator
>> MIT Computer Science and Artificial Intelligence Laboratory
>>
>>
>>
>>
>> You may also check your case on the web at:
>> https://tig.csail.mit.edu/rt/Ticket/Display.html?id=26105
>> (NOTE: access to this URL requires CSAIL web client certificate)
>>
>
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers


From teller at csail.mit.edu  Wed Mar  7 10:22:36 2007
From: teller at csail.mit.edu (Seth Teller)
Date: Wed, 07 Mar 2007 10:22:36 -0500
Subject: [Unison-hackers] unison major and minor version numbers (need
 >	2.17?)
In-Reply-To: <BAFFFB74-5E48-4188-BDC6-EF2853DE90A1@cis.upenn.edu>
References: <45EECC42.7020309@csail.mit.edu>
	<BAFFFB74-5E48-4188-BDC6-EF2853DE90A1@cis.upenn.edu>
Message-ID: <45EED8BC.5090704@csail.mit.edu>


thank you.  we'll await the stable version.

seth

Benjamin Pierce wrote:
> Hi Seth,
> 
> Here's how Unison's version numbers work: The "2" at the beginning is  
> more or less a constant.  The middle number tracks changes to the  
> communication protocol: it gets incremented whenever something  
> changes that could cause confusion if client and server were running  
> different versions.  The last number is incremented automatically on  
> each svn checkin.
> 
> Version 2.27 is still officially an internal developer version (so  
> the source code is only available direct from svn), but it is very  
> close to a new stable release version -- there are just a couple more  
> rough edges, which I hope to polish off in the next couple of days.
> 
> Regards,
> 
>      - Benjamin
> 
> 
> On Mar 7, 2007, at 9:29 AM, Seth Teller wrote:
> 
>> hello,
>>
>> i'm writing with a question about unison version numbers,
>> one which is not (fully) addressed by the FAQ.
>>
>> we are running 2.17.1 at MIT -- on personal laptops which
>> are administered privately, and on a lab-shared AFS server,
>> which is administered centrally.  i am experiencing fatal
>> errors when trying to initialize unison from two large
>> directory trees that differ slightly.  running unison with
>> -debug all and -debug verbose gives me no better clue as
>> to what is going wrong.  i have been advised to upgrade to
>> a newer unison.
>>
>> i found compiled windows+GTK 2.27.1 binaries posted (see
>> below), but our sysadmins want the source code themselves.
>> i understand that one can do an svn checkout and build, and
>> it seems that the minor version number is auto-incremented.
>> but where did the major number 27 come from?  is that
>> something that is propagated by some core set of developers?
>> and if so, can someone point me to "blessed" 2.27.X source?
>>
>> thanks,
>>
>> seth teller
>>
>>> Background thread:
>> noah,
>>
>> it seems that only the first two version components are
>> compared (see below).  i'll find out what the deal is
>> with 2.17 vs. 2.27.
>>
>> thanks,
>>
>> seth
>>
>>  From the unison FAQ:
>> I get something like 'Fatal error: Received unexpected header from the
>> server: expected "Unison 2.13\n" but received "Unison
>> 2.17\n\000\000\000\000", which differs at "Unison 2.17".'
>>
>> The versions of unison running on the server and the client must
>> match. (Specifically, the first two components of the version number
>> must match exactly: versions 2.24.6 and 2.24.10 will happily talk to
>> each other, but 2.17.3 and 2.24.10 will not). If all you need is the
>> textual user interface, compiling binaries for most distributions is
>> straighforward.
>>
>> ----- Forwarded message from alan.schmitt at polytechnique.org -----
>>       Date: Wed, 7 Mar 2007 08:12:02 +0100
>>       From: Alan Schmitt <alan.schmitt at polytechnique.org>
>> Reply-To: Alan Schmitt <alan.schmitt at polytechnique.org>
>>    Subject: Re: unison 2.27.1
>>         To: Seth Teller <teller at csail.mit.edu>
>>
>> On 6 mars 07, at 23:37, Seth Teller wrote:
>>
>> [Hide Quoted Text]
>>> hello --
>>>
>>> at
>>>
>>> http://alan.petitepomme.net/projets/unison/assets/Unison-2.27.1-  
>>> Gtk.zip
>>>
>>> you have posted a compiled version of unison.  can you
>>> point me to the source repository from which you
>>> compiled it?  also, how did you generate the version
>>> number 2.27.1 -- was it associated with the source
>>> version, or did you assign it yourself?
>> The version number is generated automatically, and I think it was
>> compiled from the current source in SVN (I'm not the one who
>> generated this version).
>>
>> Best,
>>
>> Alan
>>
>>
>> ----- End forwarded message -----
>>
>>
>> Quoting Noah Meyerhans via RT <help at csail.mit.edu>:
>>
>> [Hide Quoted Text]
>>> On Tue, Mar 06, 2007 at 03:10:48PM -0500, Seth Teller via RT wrote:
>>>> i found a built 2.271.1 GTK version at
>>>>
>>>>    http://alan.petitepomme.net/projets/unison/index.html
>>> Which doesn't necessarily help.  We really need the source.  That  
>>> site
>>> only has binaries for OS X and Windows.
>>>
>>> It seems like everybody who's ever released a pre-compiled binary has
>>> changed the version string.  Given how strict unison is about version
>>> matches, this is a real problem.  Since the most recent version of
>>> unison, as released by the actual unison developers, is 2.17.1, I
>>> wouldn't recommend that you use anything other than that, nor would I
>>> be comfortable installing anything else universally in CSAIL.
>>>
>>> Since there don't seem to be any pre-compiled versions of 2.27.1 for
>>> Linux, nor does the source code seem to exist, I'm not sure there's
>>> much we can do.
>>>
>>> noah
>>>
>>> --
>>> Noah Meyerhans                         System Administrator
>>> MIT Computer Science and Artificial Intelligence Laboratory
>>>
>>>
>>>
>>>
>>> You may also check your case on the web at:
>>> https://tig.csail.mit.edu/rt/Ticket/Display.html?id=26105
>>> (NOTE: access to this URL requires CSAIL web client certificate)
>>>
>> _______________________________________________
>> Unison-hackers mailing list
>> Unison-hackers at lists.seas.upenn.edu
>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
> 
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers

From bcpierce at cis.upenn.edu  Wed Mar  7 10:26:48 2007
From: bcpierce at cis.upenn.edu (Benjamin Pierce)
Date: Wed, 7 Mar 2007 10:26:48 -0500
Subject: [Unison-hackers] unison major and minor version numbers (need >
	2.17?)
In-Reply-To: <45EED4A2.4000209@csail.mit.edu>
References: <45EED4A2.4000209@csail.mit.edu>
Message-ID: <F06A6F72-8039-4719-B457-1BE7238110C0@cis.upenn.edu>

Aha -- this could be very useful.  This is a known bug, but we have  
been having trouble making a repeatable example of it.

When you say "i sync A to a common, initially empty archive.  i then  
attempt to sync B to that same archive," do you mean that you are  
using *three* replicas, running unison between two pairs of them?   
(Unison uses the word "archive" for its own internal state that's  
stored between runs.)

What OS are you running on?  Linux?

Thanks,

   - Benjamin


On Mar 7, 2007, at 10:05 AM, Seth Teller wrote:

>
> hello,
>
> in case it's easier to just solve my original problem:
> the output of unison -debug all is excerpted below up
> to the point of
>
>    Fatal error: Internal error: New archives are not identical.
>
> does anyone know why this is occurring and how to fix it?
>
> the usage scenario is that i have two laptops A and B with
> slightly different directory trees.  i sync A to a common,
> initially empty archive.  i then attempt to sync B to that
> same archive.  the fatal error below issues, repeatably.
>
> thanks,
>
> seth
>
>
>
> [remote_emit] Remaining tokens: 00\000\000\015\000\000...' 35 bytes
> [server: remote_emit] Received the write permission
> [server: remote_emit] Received write token (1)
> [remote_emit] Restarting readeren
> [remote_emit] Waiting for next message
> [server: remote_emit] Waiting for next message
> [server: update] Saving archive in
> /afs/csail.mit.edu/u/s/seth/.unison/sce67c05688562d423b0f0ff094369de99
> [server: remote_emit] Sending result (id: 15)
> [server: remote_emit] send [prepareCommit-res]
> '\132\149\166\190\000\000\000\006\000\000...' 26 bytes
> [server: remote_emit] send [rsp]
> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
> [server: remote_emit] Remaining tokens: 0
> [server: remote_emit] Sending write token
> [server: remote_emit] Message received (id: 16) (tokens: 1)
> [server: remote_emit] receive 'rsp\132\149\166\190\000\000\000...' 38
> bytes[remote_emit] Message received (id: 16) (toke
> ns: 1)
> [remote_emit] receive 'rsp???+\000\000\000...' 24 bytes
> [server: remote_emit] receive 'unlockArch...' 76 bytes
> [server: remote_emit] Waiting for next message
> [server: remote_emit] Received the write permission
> [server: remote_emit] Received write token (1)<
>> [server: remote_emit] Waiting for next message!
> [server: remote_emit] Sending result (id: 16)
> [server: remote_emit] send [unlockArchive-res]
> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
> [server: remote_emit] send [rsp]
> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
> [server: remote_emit] Remaining tokens: 0?+\000\000\000&\000 
> \000...' 58
> bytes
> [server: remote_emit] Sending write token0\013\000\000...' 33 bytes
> <>!<>![server: remote_emit] Message received (id: 17) (tokens: 1)
> [server: remote_emit] receive 'rsp\132\149\166\190\000\000\000...'  
> 36 bytes
> [server: remote_emit] receive 'dumpArchiv...' 74 bytes
> [server: remote_emit] Waiting for next message[remote_emit] Message
> received (id: 17) (tokens: 1)
> [server: remote_emit] Received the write permissionytes
> [server: remote_emit] Received write token (1)d
> Settings\seth\Desktop\unison\unison.dump'
> [server: remote_emit] Waiting for next message
> [server: update] Dumping archive into
> `/afs/csail.mit.edu/u/s/seth/unison.dump'
> [server: remote_emit] Sending result (id: 17)
> [server: remote_emit] send [dumpArchive-res]
> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
> [server: remote_emit] send [rsp]
> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes identical.
> [server: remote_emit] Remaining tokens: 0Unison again to bring them up
> to date.
> [server: remote_emit] Sending write token
> Fatal error: Internal error: New archives are not identical.
> C:\Documents and Settings\seth\Desktop>REM  > "C:\Documents and
> Settings\seth\Desktop\unison.txt" &
>
> C:\Documents and Settings\seth\Desktop>REM tail -f "C:\Documents and
> Settings\seth\Desktop\unison.txt"
>
> C:\Documents and Settings\seth\Desktop>REM wait until ctrl-C or window
> is closed
>
> C:\Documents and Settings\seth\Desktop>pause
> Press any key to continue . . . [server: remote] Connection closed by
> the client
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>


From teller at csail.mit.edu  Wed Mar  7 10:30:10 2007
From: teller at csail.mit.edu (Seth Teller)
Date: Wed, 07 Mar 2007 10:30:10 -0500
Subject: [Unison-hackers] unison major and minor version numbers (need
 >	2.17?)
In-Reply-To: <F06A6F72-8039-4719-B457-1BE7238110C0@cis.upenn.edu>
References: <45EED4A2.4000209@csail.mit.edu>
	<F06A6F72-8039-4719-B457-1BE7238110C0@cis.upenn.edu>
Message-ID: <45EEDA82.9050009@csail.mit.edu>


nope, i am running in the recommended "star" topology,
with a linux-unison on the CSAIL machine managing an
archive under AFS, and two laptops, each sync'ing
separately to the AFS archive (which i never use
directly -- that is, i work only on the laptops).

the laptops are running windows XP.

seth

Benjamin Pierce wrote:
> Aha -- this could be very useful.  This is a known bug, but we have  
> been having trouble making a repeatable example of it.
> 
> When you say "i sync A to a common, initially empty archive.  i then  
> attempt to sync B to that same archive," do you mean that you are  
> using *three* replicas, running unison between two pairs of them?   
> (Unison uses the word "archive" for its own internal state that's  
> stored between runs.)
> 
> What OS are you running on?  Linux?
> 
> Thanks,
> 
>    - Benjamin
> 
> 
> On Mar 7, 2007, at 10:05 AM, Seth Teller wrote:
> 
>> hello,
>>
>> in case it's easier to just solve my original problem:
>> the output of unison -debug all is excerpted below up
>> to the point of
>>
>>    Fatal error: Internal error: New archives are not identical.
>>
>> does anyone know why this is occurring and how to fix it?
>>
>> the usage scenario is that i have two laptops A and B with
>> slightly different directory trees.  i sync A to a common,
>> initially empty archive.  i then attempt to sync B to that
>> same archive.  the fatal error below issues, repeatably.
>>
>> thanks,
>>
>> seth
>>
>>
>>
>> [remote_emit] Remaining tokens: 00\000\000\015\000\000...' 35 bytes
>> [server: remote_emit] Received the write permission
>> [server: remote_emit] Received write token (1)
>> [remote_emit] Restarting readeren
>> [remote_emit] Waiting for next message
>> [server: remote_emit] Waiting for next message
>> [server: update] Saving archive in
>> /afs/csail.mit.edu/u/s/seth/.unison/sce67c05688562d423b0f0ff094369de99
>> [server: remote_emit] Sending result (id: 15)
>> [server: remote_emit] send [prepareCommit-res]
>> '\132\149\166\190\000\000\000\006\000\000...' 26 bytes
>> [server: remote_emit] send [rsp]
>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>> [server: remote_emit] Remaining tokens: 0
>> [server: remote_emit] Sending write token
>> [server: remote_emit] Message received (id: 16) (tokens: 1)
>> [server: remote_emit] receive 'rsp\132\149\166\190\000\000\000...' 38
>> bytes[remote_emit] Message received (id: 16) (toke
>> ns: 1)
>> [remote_emit] receive 'rsp???+\000\000\000...' 24 bytes
>> [server: remote_emit] receive 'unlockArch...' 76 bytes
>> [server: remote_emit] Waiting for next message
>> [server: remote_emit] Received the write permission
>> [server: remote_emit] Received write token (1)<
>>> [server: remote_emit] Waiting for next message!
>> [server: remote_emit] Sending result (id: 16)
>> [server: remote_emit] send [unlockArchive-res]
>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>> [server: remote_emit] send [rsp]
>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>> [server: remote_emit] Remaining tokens: 0?+\000\000\000&\000 
>> \000...' 58
>> bytes
>> [server: remote_emit] Sending write token0\013\000\000...' 33 bytes
>> <>!<>![server: remote_emit] Message received (id: 17) (tokens: 1)
>> [server: remote_emit] receive 'rsp\132\149\166\190\000\000\000...'  
>> 36 bytes
>> [server: remote_emit] receive 'dumpArchiv...' 74 bytes
>> [server: remote_emit] Waiting for next message[remote_emit] Message
>> received (id: 17) (tokens: 1)
>> [server: remote_emit] Received the write permissionytes
>> [server: remote_emit] Received write token (1)d
>> Settings\seth\Desktop\unison\unison.dump'
>> [server: remote_emit] Waiting for next message
>> [server: update] Dumping archive into
>> `/afs/csail.mit.edu/u/s/seth/unison.dump'
>> [server: remote_emit] Sending result (id: 17)
>> [server: remote_emit] send [dumpArchive-res]
>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>> [server: remote_emit] send [rsp]
>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes identical.
>> [server: remote_emit] Remaining tokens: 0Unison again to bring them up
>> to date.
>> [server: remote_emit] Sending write token
>> Fatal error: Internal error: New archives are not identical.
>> C:\Documents and Settings\seth\Desktop>REM  > "C:\Documents and
>> Settings\seth\Desktop\unison.txt" &
>>
>> C:\Documents and Settings\seth\Desktop>REM tail -f "C:\Documents and
>> Settings\seth\Desktop\unison.txt"
>>
>> C:\Documents and Settings\seth\Desktop>REM wait until ctrl-C or window
>> is closed
>>
>> C:\Documents and Settings\seth\Desktop>pause
>> Press any key to continue . . . [server: remote] Connection closed by
>> the client
>> _______________________________________________
>> Unison-hackers mailing list
>> Unison-hackers at lists.seas.upenn.edu
>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>>
> 
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers

From Jerome.Vouillon at pps.jussieu.fr  Wed Mar  7 10:36:24 2007
From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon)
Date: Wed, 7 Mar 2007 16:36:24 +0100
Subject: [Unison-hackers] unison major and minor version numbers (need >
	2.17?)
In-Reply-To: <45EED4A2.4000209@csail.mit.edu>
References: <45EED4A2.4000209@csail.mit.edu>
Message-ID: <20070307153624.GA23739@strontium.pps.jussieu.fr>

Hello,

On Wed, Mar 07, 2007 at 10:05:06AM -0500, Seth Teller wrote:
> in case it's easier to just solve my original problem:
> the output of unison -debug all is excerpted below up
> to the point of
> 
>    Fatal error: Internal error: New archives are not identical.
> 
> does anyone know why this is occurring and how to fix it?

This is known to happen when a path your are trying to synchronize
cannot be propagated.  For instance, if you have a path ubug/foo where
the directory ubug does not exists in one of the replicas.  Could you
check in your profile whether this is the case.

-- Jerome

From teller at csail.mit.edu  Wed Mar  7 10:48:34 2007
From: teller at csail.mit.edu (Seth Teller)
Date: Wed, 07 Mar 2007 10:48:34 -0500
Subject: [Unison-hackers] unison major and minor version numbers (need >
 2.17?)
In-Reply-To: <20070307153624.GA23739@strontium.pps.jussieu.fr>
References: <45EED4A2.4000209@csail.mit.edu>
	<20070307153624.GA23739@strontium.pps.jussieu.fr>
Message-ID: <45EEDED2.5040702@csail.mit.edu>


jerome,

thanks much.  no, i have checked both sides manually and
they appear to have identical directory structures.

also, following
http://lists.seas.upenn.edu/pipermail/unison-hackers/2006-May/000447.html
there does not seem to be any instance of a given name
corresponding to a directory on one end, and to a file
on the other end.

seth

Jerome Vouillon wrote:
> Hello,
> 
> On Wed, Mar 07, 2007 at 10:05:06AM -0500, Seth Teller wrote:
>> in case it's easier to just solve my original problem:
>> the output of unison -debug all is excerpted below up
>> to the point of
>>
>>    Fatal error: Internal error: New archives are not identical.
>>
>> does anyone know why this is occurring and how to fix it?
> 
> This is known to happen when a path your are trying to synchronize
> cannot be propagated.  For instance, if you have a path ubug/foo where
> the directory ubug does not exists in one of the replicas.  Could you
> check in your profile whether this is the case.
> 
> -- Jerome

From teller at csail.mit.edu  Sat Mar 10 14:02:28 2007
From: teller at csail.mit.edu (Seth Teller)
Date: Sat, 10 Mar 2007 14:02:28 -0500
Subject: [Unison-hackers] fatal error in 2.17.1
In-Reply-To: <45EEDA82.9050009@csail.mit.edu>
References: <45EED4A2.4000209@csail.mit.edu>
	<F06A6F72-8039-4719-B457-1BE7238110C0@cis.upenn.edu>
	<45EEDA82.9050009@csail.mit.edu>
Message-ID: <45F300C4.6070707@csail.mit.edu>


benjamin,

i believe that the following scenario describes
the fatal error.

both directory structures on A and B are identical
with one exception.  each top-level dir has a
file named "Thumbs.db".  on machine A, it is a
10Kb file.  on machine B, it is a 6Kb file (so
obviously they are different on A and B).

the files have different creation dates.

unison is run with "fastcheck = true" even for
its first invocation on both A and B.

if i remove the .db files, then start all over
with a blank central archive, everything works
fine.

seth

Seth Teller wrote:
> 
> nope, i am running in the recommended "star" topology,
> with a linux-unison on the CSAIL machine managing an
> archive under AFS, and two laptops, each sync'ing
> separately to the AFS archive (which i never use
> directly -- that is, i work only on the laptops).
> 
> the laptops are running windows XP.
> 
> seth
> 
> Benjamin Pierce wrote:
>> Aha -- this could be very useful.  This is a known bug, but we have  
>> been having trouble making a repeatable example of it.
>>
>> When you say "i sync A to a common, initially empty archive.  i then  
>> attempt to sync B to that same archive," do you mean that you are  
>> using *three* replicas, running unison between two pairs of them?   
>> (Unison uses the word "archive" for its own internal state that's  
>> stored between runs.)
>>
>> What OS are you running on?  Linux?
>>
>> Thanks,
>>
>>    - Benjamin
>>
>>
>> On Mar 7, 2007, at 10:05 AM, Seth Teller wrote:
>>
>>> hello,
>>>
>>> in case it's easier to just solve my original problem:
>>> the output of unison -debug all is excerpted below up
>>> to the point of
>>>
>>>    Fatal error: Internal error: New archives are not identical.
>>>
>>> does anyone know why this is occurring and how to fix it?
>>>
>>> the usage scenario is that i have two laptops A and B with
>>> slightly different directory trees.  i sync A to a common,
>>> initially empty archive.  i then attempt to sync B to that
>>> same archive.  the fatal error below issues, repeatably.
>>>
>>> thanks,
>>>
>>> seth
>>>
>>>
>>>
>>> [remote_emit] Remaining tokens: 00\000\000\015\000\000...' 35 bytes
>>> [server: remote_emit] Received the write permission
>>> [server: remote_emit] Received write token (1)
>>> [remote_emit] Restarting readeren
>>> [remote_emit] Waiting for next message
>>> [server: remote_emit] Waiting for next message
>>> [server: update] Saving archive in
>>> /afs/csail.mit.edu/u/s/seth/.unison/sce67c05688562d423b0f0ff094369de99
>>> [server: remote_emit] Sending result (id: 15)
>>> [server: remote_emit] send [prepareCommit-res]
>>> '\132\149\166\190\000\000\000\006\000\000...' 26 bytes
>>> [server: remote_emit] send [rsp]
>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>>> [server: remote_emit] Remaining tokens: 0
>>> [server: remote_emit] Sending write token
>>> [server: remote_emit] Message received (id: 16) (tokens: 1)
>>> [server: remote_emit] receive 'rsp\132\149\166\190\000\000\000...' 38
>>> bytes[remote_emit] Message received (id: 16) (toke
>>> ns: 1)
>>> [remote_emit] receive 'rsp???+\000\000\000...' 24 bytes
>>> [server: remote_emit] receive 'unlockArch...' 76 bytes
>>> [server: remote_emit] Waiting for next message
>>> [server: remote_emit] Received the write permission
>>> [server: remote_emit] Received write token (1)<
>>>> [server: remote_emit] Waiting for next message!
>>> [server: remote_emit] Sending result (id: 16)
>>> [server: remote_emit] send [unlockArchive-res]
>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>>> [server: remote_emit] send [rsp]
>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>>> [server: remote_emit] Remaining tokens: 0?+\000\000\000&\000 \000...' 58
>>> bytes
>>> [server: remote_emit] Sending write token0\013\000\000...' 33 bytes
>>> <>!<>![server: remote_emit] Message received (id: 17) (tokens: 1)
>>> [server: remote_emit] receive 'rsp\132\149\166\190\000\000\000...'  
>>> 36 bytes
>>> [server: remote_emit] receive 'dumpArchiv...' 74 bytes
>>> [server: remote_emit] Waiting for next message[remote_emit] Message
>>> received (id: 17) (tokens: 1)
>>> [server: remote_emit] Received the write permissionytes
>>> [server: remote_emit] Received write token (1)d
>>> Settings\seth\Desktop\unison\unison.dump'
>>> [server: remote_emit] Waiting for next message
>>> [server: update] Dumping archive into
>>> `/afs/csail.mit.edu/u/s/seth/unison.dump'
>>> [server: remote_emit] Sending result (id: 17)
>>> [server: remote_emit] send [dumpArchive-res]
>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>>> [server: remote_emit] send [rsp]
>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes identical.
>>> [server: remote_emit] Remaining tokens: 0Unison again to bring them up
>>> to date.
>>> [server: remote_emit] Sending write token
>>> Fatal error: Internal error: New archives are not identical.
>>> C:\Documents and Settings\seth\Desktop>REM  > "C:\Documents and
>>> Settings\seth\Desktop\unison.txt" &
>>>
>>> C:\Documents and Settings\seth\Desktop>REM tail -f "C:\Documents and
>>> Settings\seth\Desktop\unison.txt"
>>>
>>> C:\Documents and Settings\seth\Desktop>REM wait until ctrl-C or window
>>> is closed
>>>
>>> C:\Documents and Settings\seth\Desktop>pause
>>> Press any key to continue . . . [server: remote] Connection closed by
>>> the client
>>> _______________________________________________
>>> Unison-hackers mailing list
>>> Unison-hackers at lists.seas.upenn.edu
>>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>>>
>>
>> _______________________________________________
>> Unison-hackers mailing list
>> Unison-hackers at lists.seas.upenn.edu
>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers

From bcpierce at cis.upenn.edu  Sat Mar 10 19:12:24 2007
From: bcpierce at cis.upenn.edu (Benjamin Pierce)
Date: Sat, 10 Mar 2007 19:12:24 -0500
Subject: [Unison-hackers] fatal error in 2.17.1
In-Reply-To: <45F300C4.6070707@csail.mit.edu>
References: <45EED4A2.4000209@csail.mit.edu>
	<F06A6F72-8039-4719-B457-1BE7238110C0@cis.upenn.edu>
	<45EEDA82.9050009@csail.mit.edu> <45F300C4.6070707@csail.mit.edu>
Message-ID: <24B1E4AC-DF97-48E0-9A06-F8C6E372FDDF@cis.upenn.edu>

On the first run, does Unison flag the files as conflicting?  (If so,  
I assume you chose one of them to override the other and told it to  
proceed?  Or what?)

Thanks,

    - Benjamin

On Mar 10, 2007, at 2:02 PM, Seth Teller wrote:

>
> benjamin,
>
> i believe that the following scenario describes
> the fatal error.
>
> both directory structures on A and B are identical
> with one exception.  each top-level dir has a
> file named "Thumbs.db".  on machine A, it is a
> 10Kb file.  on machine B, it is a 6Kb file (so
> obviously they are different on A and B).
>
> the files have different creation dates.
>
> unison is run with "fastcheck = true" even for
> its first invocation on both A and B.
>
> if i remove the .db files, then start all over
> with a blank central archive, everything works
> fine.
>
> seth
>
> Seth Teller wrote:
>>
>> nope, i am running in the recommended "star" topology,
>> with a linux-unison on the CSAIL machine managing an
>> archive under AFS, and two laptops, each sync'ing
>> separately to the AFS archive (which i never use
>> directly -- that is, i work only on the laptops).
>>
>> the laptops are running windows XP.
>>
>> seth
>>
>> Benjamin Pierce wrote:
>>> Aha -- this could be very useful.  This is a known bug, but we have
>>> been having trouble making a repeatable example of it.
>>>
>>> When you say "i sync A to a common, initially empty archive.  i then
>>> attempt to sync B to that same archive," do you mean that you are
>>> using *three* replicas, running unison between two pairs of them?
>>> (Unison uses the word "archive" for its own internal state that's
>>> stored between runs.)
>>>
>>> What OS are you running on?  Linux?
>>>
>>> Thanks,
>>>
>>>    - Benjamin
>>>
>>>
>>> On Mar 7, 2007, at 10:05 AM, Seth Teller wrote:
>>>
>>>> hello,
>>>>
>>>> in case it's easier to just solve my original problem:
>>>> the output of unison -debug all is excerpted below up
>>>> to the point of
>>>>
>>>>    Fatal error: Internal error: New archives are not identical.
>>>>
>>>> does anyone know why this is occurring and how to fix it?
>>>>
>>>> the usage scenario is that i have two laptops A and B with
>>>> slightly different directory trees.  i sync A to a common,
>>>> initially empty archive.  i then attempt to sync B to that
>>>> same archive.  the fatal error below issues, repeatably.
>>>>
>>>> thanks,
>>>>
>>>> seth
>>>>
>>>>
>>>>
>>>> [remote_emit] Remaining tokens: 00\000\000\015\000\000...' 35 bytes
>>>> [server: remote_emit] Received the write permission
>>>> [server: remote_emit] Received write token (1)
>>>> [remote_emit] Restarting readeren
>>>> [remote_emit] Waiting for next message
>>>> [server: remote_emit] Waiting for next message
>>>> [server: update] Saving archive in
>>>> /afs/csail.mit.edu/u/s/seth/.unison/ 
>>>> sce67c05688562d423b0f0ff094369de99
>>>> [server: remote_emit] Sending result (id: 15)
>>>> [server: remote_emit] send [prepareCommit-res]
>>>> '\132\149\166\190\000\000\000\006\000\000...' 26 bytes
>>>> [server: remote_emit] send [rsp]
>>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>>>> [server: remote_emit] Remaining tokens: 0
>>>> [server: remote_emit] Sending write token
>>>> [server: remote_emit] Message received (id: 16) (tokens: 1)
>>>> [server: remote_emit] receive 'rsp\132\149\166\190\000\000 
>>>> \000...' 38
>>>> bytes[remote_emit] Message received (id: 16) (toke
>>>> ns: 1)
>>>> [remote_emit] receive 'rsp???+\000\000\000...' 24 bytes
>>>> [server: remote_emit] receive 'unlockArch...' 76 bytes
>>>> [server: remote_emit] Waiting for next message
>>>> [server: remote_emit] Received the write permission
>>>> [server: remote_emit] Received write token (1)<
>>>>> [server: remote_emit] Waiting for next message!
>>>> [server: remote_emit] Sending result (id: 16)
>>>> [server: remote_emit] send [unlockArchive-res]
>>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>>>> [server: remote_emit] send [rsp]
>>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>>>> [server: remote_emit] Remaining tokens: 0?+\000\000\000&\000  
>>>> \000...' 58
>>>> bytes
>>>> [server: remote_emit] Sending write token0\013\000\000...' 33 bytes
>>>> <>!<>![server: remote_emit] Message received (id: 17) (tokens: 1)
>>>> [server: remote_emit] receive 'rsp\132\149\166\190\000\000\000...'
>>>> 36 bytes
>>>> [server: remote_emit] receive 'dumpArchiv...' 74 bytes
>>>> [server: remote_emit] Waiting for next message[remote_emit] Message
>>>> received (id: 17) (tokens: 1)
>>>> [server: remote_emit] Received the write permissionytes
>>>> [server: remote_emit] Received write token (1)d
>>>> Settings\seth\Desktop\unison\unison.dump'
>>>> [server: remote_emit] Waiting for next message
>>>> [server: update] Dumping archive into
>>>> `/afs/csail.mit.edu/u/s/seth/unison.dump'
>>>> [server: remote_emit] Sending result (id: 17)
>>>> [server: remote_emit] send [dumpArchive-res]
>>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>>>> [server: remote_emit] send [rsp]
>>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes identical.
>>>> [server: remote_emit] Remaining tokens: 0Unison again to bring  
>>>> them up
>>>> to date.
>>>> [server: remote_emit] Sending write token
>>>> Fatal error: Internal error: New archives are not identical.
>>>> C:\Documents and Settings\seth\Desktop>REM  > "C:\Documents and
>>>> Settings\seth\Desktop\unison.txt" &
>>>>
>>>> C:\Documents and Settings\seth\Desktop>REM tail -f "C:\Documents  
>>>> and
>>>> Settings\seth\Desktop\unison.txt"
>>>>
>>>> C:\Documents and Settings\seth\Desktop>REM wait until ctrl-C or  
>>>> window
>>>> is closed
>>>>
>>>> C:\Documents and Settings\seth\Desktop>pause
>>>> Press any key to continue . . . [server: remote] Connection  
>>>> closed by
>>>> the client
>>>> _______________________________________________
>>>> Unison-hackers mailing list
>>>> Unison-hackers at lists.seas.upenn.edu
>>>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>>>>
>>>
>>> _______________________________________________
>>> Unison-hackers mailing list
>>> Unison-hackers at lists.seas.upenn.edu
>>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>


From Jerome.Vouillon at pps.jussieu.fr  Fri Mar 16 09:24:08 2007
From: Jerome.Vouillon at pps.jussieu.fr (Jerome.Vouillon@pps.jussieu.fr)
Date: Fri, 16 Mar 2007 09:24:08 -0400
Subject: [Unison-hackers] [unison-svn] r209 - trunk/src
Message-ID: <200703161324.l2GDO8jp006469@canfield.cis.upenn.edu>

Author: vouillon
Date: 2007-03-16 09:24:08 -0400 (Fri, 16 Mar 2007)
New Revision: 209

Modified:
   trunk/src/RECENTNEWS
   trunk/src/fileinfo.ml
   trunk/src/files.ml
   trunk/src/mkProjectInfo.ml
   trunk/src/name.ml
   trunk/src/props.ml
   trunk/src/remote.ml
   trunk/src/terminal.ml
   trunk/src/update.ml
   trunk/src/update.mli
Log:
* Fixed bug regarding fastcheck and daylight saving time under Windows
  when Unison is setup to synchronize modification times.
  (Modification times cannot be updated in the archive in this case,
  thus we have to ignore one hour differences.)
* In Name.fromString, raise a transient error rather than an invalid
  argument error when a filename contains a slash '/' (this can occur
  under Windows when using some multibyte character encodings).
* Fail when a path does not point to anywhere in the filesystem, rather
  that reporting an error for this path.  Indeed, the archives can be left
  in a non-identical state in this case.
* Some clean-up in Files.checkContentsChangeLocal.  In particular, put
  the suggestion to disable fastcheck in a case where it can
  actually be reported to the user.



From Jerome.Vouillon at pps.jussieu.fr  Mon Mar 19 12:55:29 2007
From: Jerome.Vouillon at pps.jussieu.fr (Jerome.Vouillon@pps.jussieu.fr)
Date: Mon, 19 Mar 2007 12:55:29 -0400
Subject: [Unison-hackers] [unison-svn] r210 - trunk/src
Message-ID: <200703191655.l2JGtT3X002725@canfield.cis.upenn.edu>

Author: vouillon
Date: 2007-03-19 12:55:28 -0400 (Mon, 19 Mar 2007)
New Revision: 210

Modified:
   trunk/src/RECENTNEWS
   trunk/src/mkProjectInfo.ml
   trunk/src/os.ml
   trunk/src/props.ml
   trunk/src/uigtk2.ml
   trunk/src/update.ml
Log:
* Fix bug with case insensitive mode on case sensitive file systems
* Uigtk2: hide the "View details" button rather than making it insensitive
  (I find this button a bit confusing as is not clear what it is
   supposed to do)
* When deleting a directory, do not skip any file (neither temporary
  files nor lone appledouble files).  We used to skip temporary files
  corresponding to a different pair of roots, but this makes the
  directory deletion fail.



From bcpierce at cis.upenn.edu  Mon Mar 19 17:12:53 2007
From: bcpierce at cis.upenn.edu (Benjamin Pierce)
Date: Mon, 19 Mar 2007 17:12:53 -0400
Subject: [Unison-hackers] [unison-svn] r210 - trunk/src
In-Reply-To: <200703191655.l2JGtT3X002725@canfield.cis.upenn.edu>
References: <200703191655.l2JGtT3X002725@canfield.cis.upenn.edu>
Message-ID: <AF21FBF4-5165-413F-8001-6845470C6450@cis.upenn.edu>

Excellent -- many thanks, Jerome!

Pretty soon there are not going to be any bugs left and we are going  
to have to add some new new bugs to keep you entertained... :-)

    - Benjamin


On Mar 19, 2007, at 12:55 PM, Jerome.Vouillon at pps.jussieu.fr wrote:

> Author: vouillon
> Date: 2007-03-19 12:55:28 -0400 (Mon, 19 Mar 2007)
> New Revision: 210
>
> Modified:
>    trunk/src/RECENTNEWS
>    trunk/src/mkProjectInfo.ml
>    trunk/src/os.ml
>    trunk/src/props.ml
>    trunk/src/uigtk2.ml
>    trunk/src/update.ml
> Log:
> * Fix bug with case insensitive mode on case sensitive file systems
> * Uigtk2: hide the "View details" button rather than making it  
> insensitive
>   (I find this button a bit confusing as is not clear what it is
>    supposed to do)
> * When deleting a directory, do not skip any file (neither temporary
>   files nor lone appledouble files).  We used to skip temporary files
>   corresponding to a different pair of roots, but this makes the
>   directory deletion fail.
>
>
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers


From Jerome.Vouillon at pps.jussieu.fr  Tue Mar 20 05:59:51 2007
From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon)
Date: Tue, 20 Mar 2007 10:59:51 +0100
Subject: [Unison-hackers] [unison-svn] r210 - trunk/src
In-Reply-To: <AF21FBF4-5165-413F-8001-6845470C6450@cis.upenn.edu>
References: <200703191655.l2JGtT3X002725@canfield.cis.upenn.edu>
	<AF21FBF4-5165-413F-8001-6845470C6450@cis.upenn.edu>
Message-ID: <20070320095951.GB7507@strontium.pps.jussieu.fr>

On Mon, Mar 19, 2007 at 05:12:53PM -0400, Benjamin Pierce wrote:
> Pretty soon there are not going to be any bugs left and we are going  
> to have to add some new new bugs to keep you entertained... :-)

Indeed, I'm starting to run out of bugs.  Do you have any in mind that
I may have missed?

-- Jerome

From teller at csail.mit.edu  Tue Mar 20 06:31:55 2007
From: teller at csail.mit.edu (Seth Teller)
Date: Tue, 20 Mar 2007 06:31:55 -0400
Subject: [Unison-hackers] [unison-svn] r210 - trunk/src
In-Reply-To: <20070320095951.GB7507@strontium.pps.jussieu.fr>
References: <200703191655.l2JGtT3X002725@canfield.cis.upenn.edu>	<AF21FBF4-5165-413F-8001-6845470C6450@cis.upenn.edu>
	<20070320095951.GB7507@strontium.pps.jussieu.fr>
Message-ID: <45FFB81B.1080802@csail.mit.edu>


i'm not sure this is a bug, but i'm seeing extraordinarily long
delays after my unison 2.27.1 client prints

   "  Waiting for changes from server"

delays of two hours are not uncommon.  after the delay, normal
operation resumes.

archive size is moderate -- a few tens of Gb, a few thousand
files.  only a few dozen of those files have changed before
any particular unison run.

this is on a reasonably fast network connection (DSL).

seth


Jerome Vouillon wrote:
> On Mon, Mar 19, 2007 at 05:12:53PM -0400, Benjamin Pierce wrote:
>> Pretty soon there are not going to be any bugs left and we are going  
>> to have to add some new new bugs to keep you entertained... :-)
> 
> Indeed, I'm starting to run out of bugs.  Do you have any in mind that
> I may have missed?
> 
> -- Jerome
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers

From Jerome.Vouillon at pps.jussieu.fr  Tue Mar 20 07:23:02 2007
From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon)
Date: Tue, 20 Mar 2007 12:23:02 +0100
Subject: [Unison-hackers] [unison-svn] r210 - trunk/src
In-Reply-To: <45FFB81B.1080802@csail.mit.edu>
References: <200703191655.l2JGtT3X002725@canfield.cis.upenn.edu>
	<AF21FBF4-5165-413F-8001-6845470C6450@cis.upenn.edu>
	<20070320095951.GB7507@strontium.pps.jussieu.fr>
	<45FFB81B.1080802@csail.mit.edu>
Message-ID: <20070320112302.GA14175@strontium.pps.jussieu.fr>

On Tue, Mar 20, 2007 at 06:31:55AM -0400, Seth Teller wrote:
> 
> i'm not sure this is a bug, but i'm seeing extraordinarily long
> delays after my unison 2.27.1 client prints
> 
>    "  Waiting for changes from server"
> 
> delays of two hours are not uncommon.  after the delay, normal
> operation resumes.

The unison server seems to be very slow at checking for updates.
If it is running on a Windows machine, is the "fastcheck" option set
to true?  Also, this option fails to work under Windows after
day-light savings time changes if you synchronize file modification
times.  This was recently fixed.  A workaround is to remove the
archives (these are files "ar*" in the .unison directory; if you are
not sure which archives to remove, you can look at the first few lines
of their contents, which is human-readable).  You could try this.

-- Jerome

From teller at csail.mit.edu  Tue Mar 20 08:17:50 2007
From: teller at csail.mit.edu (Seth Teller)
Date: Tue, 20 Mar 2007 08:17:50 -0400
Subject: [Unison-hackers] [unison-svn] r210 - trunk/src
In-Reply-To: <20070320112302.GA14175@strontium.pps.jussieu.fr>
References: <200703191655.l2JGtT3X002725@canfield.cis.upenn.edu>	<AF21FBF4-5165-413F-8001-6845470C6450@cis.upenn.edu>	<20070320095951.GB7507@strontium.pps.jussieu.fr>	<45FFB81B.1080802@csail.mit.edu>
	<20070320112302.GA14175@strontium.pps.jussieu.fr>
Message-ID: <45FFD0EE.4030007@csail.mit.edu>


thanks.

the client is windows XP; the server is linux.

fastcheck is set to true.

are you suggesting that fastcheck is disabled, even
though i've enabled it as an option?

removing the ar files would be a huge pain; i'd have
to reinitialize the archives which would take a few
days.

thanks,

seth

Jerome Vouillon wrote:
> On Tue, Mar 20, 2007 at 06:31:55AM -0400, Seth Teller wrote:
>> i'm not sure this is a bug, but i'm seeing extraordinarily long
>> delays after my unison 2.27.1 client prints
>>
>>    "  Waiting for changes from server"
>>
>> delays of two hours are not uncommon.  after the delay, normal
>> operation resumes.
> 
> The unison server seems to be very slow at checking for updates.
> If it is running on a Windows machine, is the "fastcheck" option set
> to true?  Also, this option fails to work under Windows after
> day-light savings time changes if you synchronize file modification
> times.  This was recently fixed.  A workaround is to remove the
> archives (these are files "ar*" in the .unison directory; if you are
> not sure which archives to remove, you can look at the first few lines
> of their contents, which is human-readable).  You could try this.
> 
> -- Jerome
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers

From bcpierce at cis.upenn.edu  Tue Mar 20 08:50:45 2007
From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu)
Date: Tue, 20 Mar 2007 08:50:45 -0400
Subject: [Unison-hackers] [unison-svn] r211 - in trunk: doc src
Message-ID: <200703201250.l2KCojM1028225@canfield.cis.upenn.edu>

Author: bcpierce
Date: 2007-03-20 08:50:45 -0400 (Tue, 20 Mar 2007)
New Revision: 211

Modified:
   trunk/doc/unison-manual.tex
   trunk/src/BUGS.txt
   trunk/src/INSTALL.win32-msvc
   trunk/src/Makefile.OCaml
   trunk/src/RECENTNEWS
   trunk/src/files.ml
   trunk/src/mkProjectInfo.ml
   trunk/src/uicommon.ml
Log:
* Updates to Win32 installation instructions

* Corrections to documentation (thanks to Loic Kerloch)

* Updates to BUGS.txt



From bcpierce at cis.upenn.edu  Tue Mar 20 08:53:12 2007
From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu)
Date: Tue, 20 Mar 2007 08:53:12 -0400
Subject: [Unison-hackers] [unison-svn] r212 - trunk/src
Message-ID: <200703201253.l2KCrCVj028316@canfield.cis.upenn.edu>

Author: bcpierce
Date: 2007-03-20 08:53:11 -0400 (Tue, 20 Mar 2007)
New Revision: 212

Modified:
   trunk/src/RECENTNEWS
   trunk/src/mkProjectInfo.ml
   trunk/src/transport.ml
Log:
* Don't crash when 'merge' is invoked on a new file.




From bcpierce at cis.upenn.edu  Tue Mar 20 08:58:15 2007
From: bcpierce at cis.upenn.edu (Benjamin Pierce)
Date: Tue, 20 Mar 2007 08:58:15 -0400
Subject: [Unison-hackers] [unison-svn] r210 - trunk/src
In-Reply-To: <20070320095951.GB7507@strontium.pps.jussieu.fr>
References: <200703191655.l2JGtT3X002725@canfield.cis.upenn.edu>
	<AF21FBF4-5165-413F-8001-6845470C6450@cis.upenn.edu>
	<20070320095951.GB7507@strontium.pps.jussieu.fr>
Message-ID: <EF4B7BBA-B6FE-4357-8BAF-934895AFBD4B@cis.upenn.edu>

>> Pretty soon there are not going to be any bugs left and we are going
>> to have to add some new new bugs to keep you entertained... :-)
>
> Indeed, I'm starting to run out of bugs.  Do you have any in mind that
> I may have missed?

There was one very strange one where, under windows only, the RPC  
mechanism seemed to get confused by nested calls.  See the comment in  
Copy.tryCopyMovedFile.  This might be an interesting challenge.  :-)

A few others are listed in src/BUGS.txt...

     - Benjamin


From Jerome.Vouillon at pps.jussieu.fr  Tue Mar 20 09:19:29 2007
From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon)
Date: Tue, 20 Mar 2007 14:19:29 +0100
Subject: [Unison-hackers] [unison-svn] r210 - trunk/src
In-Reply-To: <45FFD0EE.4030007@csail.mit.edu>
References: <200703191655.l2JGtT3X002725@canfield.cis.upenn.edu>
	<AF21FBF4-5165-413F-8001-6845470C6450@cis.upenn.edu>
	<20070320095951.GB7507@strontium.pps.jussieu.fr>
	<45FFB81B.1080802@csail.mit.edu>
	<20070320112302.GA14175@strontium.pps.jussieu.fr>
	<45FFD0EE.4030007@csail.mit.edu>
Message-ID: <20070320131929.GA24108@strontium.pps.jussieu.fr>

On Tue, Mar 20, 2007 at 08:17:50AM -0400, Seth Teller wrote:
> the client is windows XP; the server is linux.
> 
> fastcheck is set to true.
> 
> are you suggesting that fastcheck is disabled, even
> though i've enabled it as an option?

It is possible that it is not working properly.  You can check this by
running Unison with the "-debug update+" option.  You will get the
following line each time fastcheck fails:

    [server: update+]   Double-check possibly updated file

The reason could be that the filesystem on the server does not
associate a fixed inode number to each file.  Then, you will have
lines such as the following with inode numbers that do not match
(here, 242105 vs 246101).

    [server: update] checkContentsChange: stamp is inode (242105) / archStamp is inode (242105) / info.inode (246101)

If this is indeed you problem, a workaround is to use the "pretendwin"
option, which tell unison to ignore the inode number.

-- Jerome

From teller at csail.mit.edu  Tue Mar 20 09:43:36 2007
From: teller at csail.mit.edu (Seth Teller)
Date: Tue, 20 Mar 2007 09:43:36 -0400
Subject: [Unison-hackers] [unison-svn] r210 - trunk/src
In-Reply-To: <20070320131929.GA24108@strontium.pps.jussieu.fr>
References: <200703191655.l2JGtT3X002725@canfield.cis.upenn.edu>	<AF21FBF4-5165-413F-8001-6845470C6450@cis.upenn.edu>	<20070320095951.GB7507@strontium.pps.jussieu.fr>	<45FFB81B.1080802@csail.mit.edu>	<20070320112302.GA14175@strontium.pps.jussieu.fr>	<45FFD0EE.4030007@csail.mit.edu>
	<20070320131929.GA24108@strontium.pps.jussieu.fr>
Message-ID: <45FFE508.8020402@csail.mit.edu>


thanks.  would this occur if the remote file system is AFS ?

Jerome Vouillon wrote:
> On Tue, Mar 20, 2007 at 08:17:50AM -0400, Seth Teller wrote:
>> the client is windows XP; the server is linux.
>>
>> fastcheck is set to true.
>>
>> are you suggesting that fastcheck is disabled, even
>> though i've enabled it as an option?
> 
> It is possible that it is not working properly.  You can check this by
> running Unison with the "-debug update+" option.  You will get the
> following line each time fastcheck fails:
> 
>     [server: update+]   Double-check possibly updated file
> 
> The reason could be that the filesystem on the server does not
> associate a fixed inode number to each file.  Then, you will have
> lines such as the following with inode numbers that do not match
> (here, 242105 vs 246101).
> 
>     [server: update] checkContentsChange: stamp is inode (242105) / archStamp is inode (242105) / info.inode (246101)
> 
> If this is indeed you problem, a workaround is to use the "pretendwin"
> option, which tell unison to ignore the inode number.
> 
> -- Jerome
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers

From Jerome.Vouillon at pps.jussieu.fr  Thu Mar 22 05:42:15 2007
From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon)
Date: Thu, 22 Mar 2007 10:42:15 +0100
Subject: [Unison-hackers] [unison-svn] r210 - trunk/src
In-Reply-To: <45FFE508.8020402@csail.mit.edu>
References: <200703191655.l2JGtT3X002725@canfield.cis.upenn.edu>
	<AF21FBF4-5165-413F-8001-6845470C6450@cis.upenn.edu>
	<20070320095951.GB7507@strontium.pps.jussieu.fr>
	<45FFB81B.1080802@csail.mit.edu>
	<20070320112302.GA14175@strontium.pps.jussieu.fr>
	<45FFD0EE.4030007@csail.mit.edu>
	<20070320131929.GA24108@strontium.pps.jussieu.fr>
	<45FFE508.8020402@csail.mit.edu>
Message-ID: <20070322094215.GB29138@strontium.pps.jussieu.fr>

On Tue, Mar 20, 2007 at 09:43:36AM -0400, Seth Teller wrote:
>
> thanks.  would this occur if the remote file system is AFS ?

I don't know.  I have explain in my previous message how you can tell.

-- Jerome

From drayside at MIT.EDU  Thu Mar 22 09:33:05 2007
From: drayside at MIT.EDU (Derek Rayside)
Date: Thu, 22 Mar 2007 09:33:05 -0400 (EDT)
Subject: [Unison-hackers] [unison-svn] r210 - trunk/src
In-Reply-To: <20070322094215.GB29138@strontium.pps.jussieu.fr>
References: <200703191655.l2JGtT3X002725@canfield.cis.upenn.edu>
	<AF21FBF4-5165-413F-8001-6845470C6450@cis.upenn.edu>
	<20070320095951.GB7507@strontium.pps.jussieu.fr>
	<45FFB81B.1080802@csail.mit.edu>
	<20070320112302.GA14175@strontium.pps.jussieu.fr>
	<45FFD0EE.4030007@csail.mit.edu>
	<20070320131929.GA24108@strontium.pps.jussieu.fr>
	<45FFE508.8020402@csail.mit.edu>
	<20070322094215.GB29138@strontium.pps.jussieu.fr>
Message-ID: <Pine.GSO.4.64L.0703220931470.22537@grumpy-fuzzball.mit.edu>

> On Tue, Mar 20, 2007 at 09:43:36AM -0400, Seth Teller wrote:
>>
>> thanks.  would this occur if the remote file system is AFS ?

Hi Seth,

My experience is that AFS (at least at CSAIL and Athena) is noticably 
slower than local file systems, although I haven't made any measurements 
of that, nor done the tests Jerome suggested.

Derek.

From Jerome.Vouillon at pps.jussieu.fr  Wed Mar 28 11:38:51 2007
From: Jerome.Vouillon at pps.jussieu.fr (Jerome.Vouillon@pps.jussieu.fr)
Date: Wed, 28 Mar 2007 11:38:51 -0400
Subject: [Unison-hackers] [unison-svn] r213 - trunk/src
Message-ID: <200703281538.l2SFcp9n026935@canfield.cis.upenn.edu>

Author: vouillon
Date: 2007-03-28 11:38:51 -0400 (Wed, 28 Mar 2007)
New Revision: 213

Modified:
   trunk/src/RECENTNEWS
   trunk/src/fileinfo.ml
   trunk/src/mkProjectInfo.ml
   trunk/src/osx.ml
   trunk/src/props.ml
Log:
* Truncate inode numbers to 31 bits, so that they can be transferred
  between 32 and 64 bit versions of Unison.
* Suggests to use the "perms" option (with a suitable value)
  when synchronizing permissions fails (for instance on a FAT
  filesystem under Unix)