lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Wellnhofer <wellnho...@aevum.de>
Subject Re: [lucy-dev] New branch LUCY-215-cf-extensions
Date Sun, 25 Mar 2012 20:18:27 GMT
On 25/03/2012 21:19, Marvin Humphrey wrote:
> On Sun, Mar 25, 2012 at 11:47 AM, Nick Wellnhofer<wellnhofer@aevum.de>  wrote:
>> My plan is to handle file or class name clashes by ignoring files or classes
>> from the include dir. This should do the right thing if you rebuild an
>> already installed extension.
>
> Yes, that makes sense.  The issue is that when the user tells you that a dir
> is both an include dir and a source dir, we must treat it as a source dir.
>
>> I don't understand why someone would want to use the same directory for
>> sources and includes, but in this case, the add_include_dir should have
>> simply no effect.
>
> It's not that they would want to, but that it's 100% certain to happen
> accidentally at some point.  When it does, CFC should either A) do what the
> user intended or B) throw a meaningful error rather than C) break in some
> arcane way.

OK, since we now also have support for multiple source directories, I 
suggest the following:

1. If a file path or class name appears twice within any of the source 
directories, then die with a meaningful error.

2. If a file path or class name appears twice within any of the include 
directories, then die a meaningful error.

3. If a file path or class name appears once in a source directory and 
also in an include directory, then use the version from the source 
directory and continue with a meaningful warning.

> IMO we should bring your branch back to trunk sooner rather than later.  How
> about this?
>
>      svn remove https://svn.apache.org/repos/asf/incubator/lucy/trunk/clownfish
>      svn move https://svn.apache.org/repos/asf/incubator/lucy/branches/LUCY-215-cf-extensions/clownfish/
> \
>          https://svn.apache.org/repos/asf/incubator/lucy/trunk/clownfish
>
> That way we don't have to deal with svn:mergeinfo properties on trunk.

I use git-svn and my usual workflow is to simply rebase a branch on top 
of trunk with git locally, and then replay all the commits one by one. 
This is pretty easy to do and avoids the hassle of svn merges.

Nick

Mime
View raw message