On 28/11/2011 7:29 AM, Mike Duigou wrote:
On Thu, 24 Nov 2011 15:39:59 +0100 Fredrik
?hrstr?m<fredrik.ohrst...@oracle.com> wrote :
When we rename directories, we lose a lot of
information in the source control system.
hg moves don't cause any of the history to be lost. Some tools (including
NetBeans) follow the history through renames and copies without any special
intervention needed by the user at all. I don't believe this should be an
impediment.
Necessary yes, but at least we should try to do it just once.
As for the naming:
posix is the name of a standardized API to unix-like operating systems.
winapi is the name of the defacto API to windows systems.
No-one answered my question if we need to track the posix pedigree? I.e.
gnu, sysv and bsd?
Only if necessary hopefully. As we have shared and platform code we might have
shared
|--posix
| |--SYSV
| | |--solaris
| | |--aix
| |
| |--gnu
| | |--linux
| | |
| |--BSD
| |--darwin
| |--freebsd
|
|--winapi
|--win32
|--wince
Maybe I'm miinterpreting what the above means, but the use of "posix"
above would seem inappropriate. If you really mean the standard POSIX
API's then the hierarchy would have POSIX as a sibling of BSD and SYSV -
as they each define specific APIs that might be provided by an OS (eg
Solaris) and used by the VM. If you mean "posix" to be "generic unix
like OS" then the name should reflect that.
I don't think we need to get to this degree of separation in one jump.
First step would be to factor out the common POSIX API code and then
pair that with OS-specific code. If there is still enough shared code
between OS's that we can identify as BSD or SYSV or whatever, then we
could further refactor. Though I'm unclear exactly how the refactoring
would work at the file and class/function level.
David
This is an imaginary sharing/specialization hierarchy, not the source
hierarchy. Only the nodes that are actually required would need to exist--if
there is no specialization needed between darwin and freebsd then neither node
need exist.
