From julian at cipht.net  Thu Jan  1 10:42:22 2015
From: julian at cipht.net (Julian Squires)
Date: Thu, 1 Jan 2015 10:42:22 -0500
Subject: [Unison-hackers] treating some directories atomically,
	and ignoring socket files
Message-ID: <CAEbLoBL65L2MonUtekcjzxjLZ8rRYvpAh4-ysycsJ+rxsfj9Ew@mail.gmail.com>

Hi,

I was contacted by a client to add two features to Unison for them,
and although I implemented something that worked for them, I'd like to
ask here about how to approach their implementation in a way that
might be accepted upstream.

The first is to ignore Unix domain socket files, which I did by
returning `ABSENT in Fileinfo.get when such a file is encountered.
I've attached some patches for this, but I realized later that my test
could be cleaner, as I didn't fully understand the test scaffold when
I first approached it.

The second is to treat VCS directories (such as .git or .svn)
atomically; that is, all the changes under such a directory should be
reconciled in the same direction, not merged.

For this feature, I provided a workaround for the client that adds a
predicate preference "atomic" which specifies directories to treat in
this manner, and then in Update.buildUpdateRec I treat anything within
those directories as new if there's been any change.  This seems to
work for them, but is clearly pretty inelegant and far from the
cleanest solution.

I had the suspicion that the best-integrated solution would be to
create a new file type like `ATOMIC_DIRECTORY so that the UI could
present it as a single entry, but it would be otherwise processed like
a directory.

I suspect that this would be too invasive a change for such a patch to
ever get merged upstream, though, which is why I'm hoping the members
of this list will have some suggestions.

I've attached patches for ignoring Unix socket files, which may need
some changes, but is probably otherwise uncontroversial.

Thanks,

-- 
Julian Squires
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-Unix-domain-sockets-test-scaffold.patch
Type: text/x-diff
Size: 1992 bytes
Desc: not available
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20150101/0e2844eb/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Add-trivial-test-for-Unix-sockets.patch
Type: text/x-diff
Size: 992 bytes
Desc: not available
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20150101/0e2844eb/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Ignore-socket-files.patch
Type: text/x-diff
Size: 716 bytes
Desc: not available
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20150101/0e2844eb/attachment-0005.bin>

From ats at acm.org  Thu Jan  1 10:57:05 2015
From: ats at acm.org (Alan Shutko)
Date: Thu, 1 Jan 2015 09:57:05 -0600
Subject: [Unison-hackers] treating some directories atomically,
	and ignoring socket files
In-Reply-To: <CAEbLoBL65L2MonUtekcjzxjLZ8rRYvpAh4-ysycsJ+rxsfj9Ew@mail.gmail.com>
References: <CAEbLoBL65L2MonUtekcjzxjLZ8rRYvpAh4-ysycsJ+rxsfj9Ew@mail.gmail.com>
Message-ID: <DAABC4CB-BE7F-4255-918E-56A1F5B59029@acm.org>


> On Jan 1, 2015, at 9:42 AM, Julian Squires <julian at cipht.net> wrote:
> 
> I had the suspicion that the best-integrated solution would be to
> create a new file type like `ATOMIC_DIRECTORY so that the UI could
> present it as a single entry, but it would be otherwise processed like
> a directory.

I would like to see a feature like this as well.  On Mac, we have packages which are directories that are treated as a single unit. There are many programs which use packages as a document format, and there are the same concerns as VC directories.  

From rrnewton at gmail.com  Thu Jan  1 14:10:16 2015
From: rrnewton at gmail.com (Ryan Newton)
Date: Thu, 01 Jan 2015 19:10:16 +0000
Subject: [Unison-hackers] treating some directories atomically,
 and ignoring socket files
References: <CAEbLoBL65L2MonUtekcjzxjLZ8rRYvpAh4-ysycsJ+rxsfj9Ew@mail.gmail.com>
 <DAABC4CB-BE7F-4255-918E-56A1F5B59029@acm.org>
Message-ID: <CACYs5AbQ-xzUD9gzVHO3j77zNC+m_1ngpO11KqhA+ce9DiPH4A@mail.gmail.com>

+1, it would be great to have this for .git directories.

On Thu Jan 01 2015 at 11:03:09 AM Alan Shutko <ats at acm.org> wrote:

>
> > On Jan 1, 2015, at 9:42 AM, Julian Squires <julian at cipht.net> wrote:
> >
> > I had the suspicion that the best-integrated solution would be to
> > create a new file type like `ATOMIC_DIRECTORY so that the UI could
> > present it as a single entry, but it would be otherwise processed like
> > a directory.
>
> I would like to see a feature like this as well.  On Mac, we have packages
> which are directories that are treated as a single unit. There are many
> programs which use packages as a document format, and there are the same
> concerns as VC directories.
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20150101/2049c2ac/attachment.html>

From chris.prince at gmail.com  Thu Jan  1 14:10:51 2015
From: chris.prince at gmail.com (Chris Prince)
Date: Thu, 1 Jan 2015 11:10:51 -0800
Subject: [Unison-hackers] treating some directories atomically,
 and ignoring socket files
In-Reply-To: <DAABC4CB-BE7F-4255-918E-56A1F5B59029@acm.org>
References: <CAEbLoBL65L2MonUtekcjzxjLZ8rRYvpAh4-ysycsJ+rxsfj9Ew@mail.gmail.com>
 <DAABC4CB-BE7F-4255-918E-56A1F5B59029@acm.org>
Message-ID: <CAJQbe9n-FphJCkFPGqr368kBUHTDJODrBQjoSS9iw8WfJj5W+w@mail.gmail.com>

>> On Jan 1, 2015, at 9:42 AM, Julian Squires <julian at cipht.net> wrote:
>>
>> I had the suspicion that the best-integrated solution would be to
>> create a new file type like `ATOMIC_DIRECTORY so that the UI could
>> present it as a single entry, but it would be otherwise processed like
>> a directory.
>
On Thu, Jan 1, 2015 at 7:57 AM, Alan Shutko <ats at acm.org> wrote:
>
> I would like to see a feature like this as well.  On Mac, we have packages
> which are directories that are treated as a single unit. There are many
> programs which use packages as a document format, and there are the
> same concerns as VC directories.

I have also wanted a similar feature, for synchronizing directories with
many changes.

But to keep the feature general-purpose, I imagined the following: the text
UI would let you move "up" in the directory hierarchy (even multiple
levels) and apply an action to all changes below the higher directory.

For example, if you had the following differences in today's UI:

changed  ---->            Work/.git/index  [f]
new file ---->            Work/.git/objects/01/488ce102abf6  [f]
new file ---->            Work/.git/objects/01/a5023bc92349  [f]
  [snip tens or hundreds of similar lines]
new file ---->            Work/.git/objects/ff/eaa8085e4b3d  [f]
deleted  ---->            Work/temp.txt  [f]

The new UI would let you do the following instead. (Notice the 'up' action
taken on the first line, and the 'various' status on the second line.)

changed  ---->            Work/.git/index  [f] u
various  ---->            Work/.git  [f]
deleted  ---->            Work/temp.txt  [f]

---Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20150101/721b4c92/attachment.html>

From julian at cipht.net  Wed Jan 14 08:31:48 2015
From: julian at cipht.net (Julian Squires)
Date: Wed, 14 Jan 2015 08:31:48 -0500
Subject: [Unison-hackers] treating some directories atomically,
	and ignoring socket files
In-Reply-To: <CAEbLoBL65L2MonUtekcjzxjLZ8rRYvpAh4-ysycsJ+rxsfj9Ew@mail.gmail.com>
References: <CAEbLoBL65L2MonUtekcjzxjLZ8rRYvpAh4-ysycsJ+rxsfj9Ew@mail.gmail.com>
Message-ID: <CAEbLoBKobC2P=XBfjdOPj4r9=A4uAt6fu+YdStfPBYuDweM8BA@mail.gmail.com>

Thanks for the feedback, everyone.  I like the idea of the "up" action
in the text UI, but implementing it right now was outside the scope of
what I was working on.

I've attached patches that implement an atomic option, so you can
specify, e.g., "-atomic Name\ .git -atomic Name\ .svn", and these
directories will be treated indivisibly.  Presumably one can use the
pattern matching facilities of this kind of predicate to match
packages on OS X but I haven't investigated it.

I have no doubt there are improvements that can be made to how I have
implemented this, so I welcome your comments.

-- 
Julian Squires
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-atomic-option-as-a-global-predicate.patch
Type: text/x-diff
Size: 1436 bytes
Desc: not available
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20150114/4c115206/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Add-acceptance-test-for-git-directory-atomicity.patch
Type: text/x-diff
Size: 2519 bytes
Desc: not available
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20150114/4c115206/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Add-handling-of-atomic-directories.patch
Type: text/x-diff
Size: 4700 bytes
Desc: not available
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20150114/4c115206/attachment-0005.bin>

From julian at cipht.net  Wed Jan 28 16:36:59 2015
From: julian at cipht.net (Julian Squires)
Date: Wed, 28 Jan 2015 16:36:59 -0500
Subject: [Unison-hackers] treating some directories atomically,
	and ignoring socket files
In-Reply-To: <CAEbLoBKobC2P=XBfjdOPj4r9=A4uAt6fu+YdStfPBYuDweM8BA@mail.gmail.com>
References: <CAEbLoBL65L2MonUtekcjzxjLZ8rRYvpAh4-ysycsJ+rxsfj9Ew@mail.gmail.com>
 <CAEbLoBKobC2P=XBfjdOPj4r9=A4uAt6fu+YdStfPBYuDweM8BA@mail.gmail.com>
Message-ID: <CAEbLoB+mK60HrijBSxwzsyEH6Vud1YZM+ZXUFN5DJgJomMLxQw@mail.gmail.com>

Hi unison-hackers,

I'm just wondering if my previous patches made it through and whether
there's anything I could do to improve them and get them added to
Unison.

Thanks.

-- 
Julian Squires

From jan at hacker.ch  Wed Jan 28 17:59:55 2015
From: jan at hacker.ch (Jan Hacker)
Date: Wed, 28 Jan 2015 23:59:55 +0100
Subject: [Unison-hackers] uimac14: TheGrowl vs NotificationCenter
Message-ID: <FA933109-752A-4AE3-8630-FDDE99C73216@hacker.ch>

Dear unison-hackers,

I recently wanted to build the latest stable version of unison for OSX Yosemite.
I think TheGrowl is considered 'legacy' in the meantime -- as OS X rolls its own
Notification(s)/Center... So I patched Unison (or more precisely: the uimac14) 
to drop TheGrowl in favour of the OSX-builtin approach.

It 'works-for-me' so I thought I'd share the patch (against current SVN trunk).
Please try:
  curl http://n.ethz.ch/~hackerj/unison-nogrowl.patch | patch -p1
  make UISTYLE=mac14

The actual few lines changed are at the bottom of the patch, the beginning is
all about dropping TheGrowl -- maybe it's a bit too much to drop it completely
'yet'? At least for me ;), it results in a build that seems to work somewhat
smoothly (e.g. Notification settings for Unison.app can be controlled via
System Preferences' "Notifications" panel).

I've also thought about adding the possibility to let GUI users delete
(or even edit?) profiles...

Any thoughts?

thanks for unison/uimac14!
cheers,
jan


PS. I don't know whether this intentional or not ... but my own builds of
Unison.app lacked the application version string to be displayed in
'Get Info...' dialog of Finder. For my packaging purposes, I did a
/usr/libexec/PlistBuddy -c "add CFBundleShortVersionString string ${VERSION}" package_root/Applications/Unison.app/Contents/Info.plist
... maybe something like this could make it somewhere into the Makefile?

From marcos at athanasoulis.net  Wed Jan 28 22:26:43 2015
From: marcos at athanasoulis.net (Marcos Athanasoulis)
Date: Wed, 28 Jan 2015 19:26:43 -0800
Subject: [Unison-hackers] Problem with error setting a watch
Message-ID: <CANWCOGqD4d=5Hx5uP8ZG7=6PpAj8FEUoY3=z6EFzuoeGYDDiCg@mail.gmail.com>

Hi,

I am having an issue.  I replicated it with the following basic setup:

Server 1:

/ssd/unitest (directory being synced and watched)

Server 2

/home/unitest (remote directory synced and watched

If I create a new directory (in this example test1) on
server2://home/unitest/test1

The directory is properly synced back to server 1, but an error is
generated when trying to put a watch on the directory:

[2015-01-28 19:16:14,548 pyinotify ERROR] add_watch: cannot watch
/ssd/unitest/.unison.test1.70cf75d5f3a77222c5327ba3780dce0e.unison.tmp
WD=-1 Errno=No such file or directory (ENOENT)

And the directory test1 does exist, but it almost seems like it is
attempting to watch the temporary file unison creates and then renames to
the actual file name.  But when I turn on debug I can see (I think) that at
the point it is setting the watch the file has already been renamed to
test1 from the unison.tmp file, which it seems to be trying to set the
watch on (though it does not exist at that point).

This seems like it would be a common use case and I don't see anyone
posting similar issues.  Any ideas?

Thanks so much.  (And sidenote, extremely impressed and pleased with Unison
it has solved a big problem for me!)

I am on CentOS 6 (up to date) and Unison 2.48.3.

Here is the whole update session with the failure:

Looking for changes
  Waiting for changes from server
Reconciling changes
         <---- dir        test1
local        : absent
web02.the... : dir                modified on 2015-01-28 at 19:16:13  size
0         rwxr-xr-x user=0 group=0
Propagating updates
UNISON 2.48.3 started propagating changes at 19:16:14.54 on 28 Jan 2015
[BGN] Copying test1 from //web02.thehcn.net//home/unitest to /ssd/unitest
[END] Copying test1
UNISON 2.48.3 finished propagating changes at 19:16:14.54 on 28 Jan 2015
Saving synchronizer state
[2015-01-28 19:16:14,548 pyinotify ERROR] add_watch: cannot watch
/ssd/unitest/.unison.test1.70cf75d5f3a77222c5327ba3780dce0e.unison.tmp
WD=-1 Errno=No such file or directory (ENOENT)
Synchronization complete at 19:16:14  (1 item transferred, 0 skipped, 0
failed)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20150128/63113f54/attachment.html>

From marcos at athanasoulis.net  Wed Jan 28 22:39:47 2015
From: marcos at athanasoulis.net (Marcos Athanasoulis)
Date: Wed, 28 Jan 2015 19:39:47 -0800
Subject: [Unison-hackers] Problem with error setting a watch
In-Reply-To: <CANWCOGqD4d=5Hx5uP8ZG7=6PpAj8FEUoY3=z6EFzuoeGYDDiCg@mail.gmail.com>
References: <CANWCOGqD4d=5Hx5uP8ZG7=6PpAj8FEUoY3=z6EFzuoeGYDDiCg@mail.gmail.com>
Message-ID: <CANWCOGoqpW1RAab8iMswbF+cWpzM6WtBz24Oqs_91UhLU1D6Cg@mail.gmail.com>

Apologies, I just realized this isn't really a developers posting.  So
please ignore/delete I will repost to the users forum.

[May have some code contributions in the future though!]



On Wed, Jan 28, 2015 at 7:26 PM, Marcos Athanasoulis <
marcos at athanasoulis.net> wrote:

> Hi,
>
> I am having an issue.  I replicated it with the following basic setup:
>
> Server 1:
>
> /ssd/unitest (directory being synced and watched)
>
> Server 2
>
> /home/unitest (remote directory synced and watched
>
> If I create a new directory (in this example test1) on
> server2://home/unitest/test1
>
> The directory is properly synced back to server 1, but an error is
> generated when trying to put a watch on the directory:
>
> [2015-01-28 19:16:14,548 pyinotify ERROR] add_watch: cannot watch
> /ssd/unitest/.unison.test1.70cf75d5f3a77222c5327ba3780dce0e.unison.tmp
> WD=-1 Errno=No such file or directory (ENOENT)
>
> And the directory test1 does exist, but it almost seems like it is
> attempting to watch the temporary file unison creates and then renames to
> the actual file name.  But when I turn on debug I can see (I think) that at
> the point it is setting the watch the file has already been renamed to
> test1 from the unison.tmp file, which it seems to be trying to set the
> watch on (though it does not exist at that point).
>
> This seems like it would be a common use case and I don't see anyone
> posting similar issues.  Any ideas?
>
> Thanks so much.  (And sidenote, extremely impressed and pleased with
> Unison it has solved a big problem for me!)
>
> I am on CentOS 6 (up to date) and Unison 2.48.3.
>
> Here is the whole update session with the failure:
>
> Looking for changes
>   Waiting for changes from server
> Reconciling changes
>          <---- dir        test1
> local        : absent
> web02.the... : dir                modified on 2015-01-28 at 19:16:13  size
> 0         rwxr-xr-x user=0 group=0
> Propagating updates
> UNISON 2.48.3 started propagating changes at 19:16:14.54 on 28 Jan 2015
> [BGN] Copying test1 from //web02.thehcn.net//home/unitest to /ssd/unitest
> [END] Copying test1
> UNISON 2.48.3 finished propagating changes at 19:16:14.54 on 28 Jan 2015
> Saving synchronizer state
> [2015-01-28 19:16:14,548 pyinotify ERROR] add_watch: cannot watch
> /ssd/unitest/.unison.test1.70cf75d5f3a77222c5327ba3780dce0e.unison.tmp
> WD=-1 Errno=No such file or directory (ENOENT)
> Synchronization complete at 19:16:14  (1 item transferred, 0 skipped, 0
> failed)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20150128/9a1e921a/attachment.html>

From alan.schmitt at polytechnique.org  Thu Jan 29 06:07:38 2015
From: alan.schmitt at polytechnique.org (Alan Schmitt)
Date: Thu, 29 Jan 2015 12:07:38 +0100
Subject: [Unison-hackers] uimac14: TheGrowl vs NotificationCenter
In-Reply-To: <FA933109-752A-4AE3-8630-FDDE99C73216@hacker.ch> (Jan Hacker's
 message of "Wed, 28 Jan 2015 23:59:55 +0100")
References: <FA933109-752A-4AE3-8630-FDDE99C73216@hacker.ch>
Message-ID: <m2k305975x.fsf@charm-wifi.irisa.fr>

On 2015-01-28 23:59, Jan Hacker <jan at hacker.ch> writes:

> Dear unison-hackers,
>
> I recently wanted to build the latest stable version of unison for OSX Yosemite.
> I think TheGrowl is considered 'legacy' in the meantime -- as OS X rolls its own
> Notification(s)/Center... So I patched Unison (or more precisely: the uimac14) 
> to drop TheGrowl in favour of the OSX-builtin approach.

I'm very much in favor of this. One followup question: what OS X version
is required to use its notification?

Thanks,

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 494 bytes
Desc: not available
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20150129/cdc79f72/attachment.asc>

From jan at hacker.ch  Thu Jan 29 15:44:11 2015
From: jan at hacker.ch (Jan Hacker)
Date: Thu, 29 Jan 2015 21:44:11 +0100
Subject: [Unison-hackers] uimac14: TheGrowl vs NotificationCenter
In-Reply-To: <m2k305975x.fsf@charm-wifi.irisa.fr>
References: <FA933109-752A-4AE3-8630-FDDE99C73216@hacker.ch>
 <m2k305975x.fsf@charm-wifi.irisa.fr>
Message-ID: <BDC17AB6-3443-4DD8-8870-B1BAC0DF2015@hacker.ch>

On 29 Jan 2015, at 12:07 , Alan Schmitt <alan.schmitt at polytechnique.org> wrote:

> On 2015-01-28 23:59, Jan Hacker <jan at hacker.ch> writes:
>> Notification(s)/Center... So I patched Unison (or more precisely: the uimac14) 
>> to drop TheGrowl in favour of the OSX-builtin approach.
> I'm very much in favor of this. One followup question: what OS X version
> is required to use its notification?

According to this article I hadn't seen before, too, .... 10.8.
http://en.wikipedia.org/wiki/Notification_Center

kind regards,
jan

From alan.schmitt at polytechnique.org  Fri Jan 30 02:11:17 2015
From: alan.schmitt at polytechnique.org (Alan Schmitt)
Date: Fri, 30 Jan 2015 08:11:17 +0100
Subject: [Unison-hackers] uimac14: TheGrowl vs NotificationCenter
In-Reply-To: <BDC17AB6-3443-4DD8-8870-B1BAC0DF2015@hacker.ch> (Jan Hacker's
 message of "Thu, 29 Jan 2015 21:44:11 +0100")
References: <FA933109-752A-4AE3-8630-FDDE99C73216@hacker.ch>
 <m2k305975x.fsf@charm-wifi.irisa.fr>
 <BDC17AB6-3443-4DD8-8870-B1BAC0DF2015@hacker.ch>
Message-ID: <m2twz87nfu.fsf@charm-wifi.irisa.fr>

On 2015-01-29 21:44, Jan Hacker <jan at hacker.ch> writes:

> On 29 Jan 2015, at 12:07 , Alan Schmitt <alan.schmitt at polytechnique.org> wrote:
>
>> On 2015-01-28 23:59, Jan Hacker <jan at hacker.ch> writes:
>>> Notification(s)/Center... So I patched Unison (or more precisely: the uimac14) 
>>> to drop TheGrowl in favour of the OSX-builtin approach.
>> I'm very much in favor of this. One followup question: what OS X version
>> is required to use its notification?
>
> According to this article I hadn't seen before, too, .... 10.8.
> http://en.wikipedia.org/wiki/Notification_Center

OK. Do we want to cut support for 10.7 or earlier, or do we want to
provide several binaries (using MAC_OS_X_VERSION_MIN_REQUIRED and
changing the target version)?

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 494 bytes
Desc: not available
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20150130/7bdc7170/attachment.asc>

From moonkid at posteo.org  Fri Jan 30 05:47:22 2015
From: moonkid at posteo.org (moonkid at posteo.org)
Date: Fri, 30 Jan 2015 11:47:22 +0100
Subject: [Unison-hackers] howto: IgnorePath?
Message-ID: <201501301047.t0UAlWul012705@psychopathy.seas.upenn.edu>

I don't get my IgnorePath variables running. ;)

e.g. "share/work/.out/box.aux"

I want all ".out" Folders and their child-folders/-files be ignored
while syncing.

But this variants doesn't work:
"ignore = Path {.out}"
"ignore = Path {*/.out}"
"ignore = Path {*/.out/*}"

The aux-file below always appear in the sync.

From bcpierce at cis.upenn.edu  Fri Jan 30 17:06:29 2015
From: bcpierce at cis.upenn.edu (Benjamin Pierce)
Date: Fri, 30 Jan 2015 17:06:29 -0500
Subject: [Unison-hackers] uimac14: TheGrowl vs NotificationCenter
In-Reply-To: <m2twz87nfu.fsf@charm-wifi.irisa.fr>
References: <FA933109-752A-4AE3-8630-FDDE99C73216@hacker.ch>
 <m2k305975x.fsf@charm-wifi.irisa.fr>
 <BDC17AB6-3443-4DD8-8870-B1BAC0DF2015@hacker.ch>
 <m2twz87nfu.fsf@charm-wifi.irisa.fr>
Message-ID: <852B6F32-E5C6-4FAB-A85D-E1D10E30CC67@cis.upenn.edu>

10.7 is pretty old, now.  I would advocate dropping support for it, unless it?s very easy to keep it...

      - Benjamin

> On Jan 30, 2015, at 2:11 AM, Alan Schmitt <alan.schmitt at polytechnique.org> wrote:
> 
> On 2015-01-29 21:44, Jan Hacker <jan at hacker.ch> writes:
> 
>> On 29 Jan 2015, at 12:07 , Alan Schmitt <alan.schmitt at polytechnique.org> wrote:
>> 
>>> On 2015-01-28 23:59, Jan Hacker <jan at hacker.ch> writes:
>>>> Notification(s)/Center... So I patched Unison (or more precisely: the uimac14) 
>>>> to drop TheGrowl in favour of the OSX-builtin approach.
>>> I'm very much in favor of this. One followup question: what OS X version
>>> is required to use its notification?
>> 
>> According to this article I hadn't seen before, too, .... 10.8.
>> http://en.wikipedia.org/wiki/Notification_Center
> 
> OK. Do we want to cut support for 10.7 or earlier, or do we want to
> provide several binaries (using MAC_OS_X_VERSION_MIN_REQUIRED and
> changing the target version)?
> 
> Alan
> 
> -- 
> OpenPGP Key ID : 040D0A3B4ED2E5C7
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20150130/f7415806/attachment.html>