Mark Banner wrote:
This would also simplify our release processes and the
source control systems a user has to interact with.
That's why I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=506601
(to be discussed here)
Lately, I started to look into some bugs involving the ldap c-sdk,
and managing cvs patches feels like a pain to me compared to hg (mq),
so I gave up.
a) Move LDAP SDK development to Mercurial.
The slight downside of this for comm-central is that comm-central would
have to decide what to do with its current directory/xpcom files
Another downside is that c-c (and other projects) would have to pull the
whole ldap repo, instead of just the (c-)sdk directory it needs.
Fwiw, a (Mercurial 1.3, "experimental") solution could be
http://mercurial.selenic.com/wiki/NestedRepositories
http://mercurial.selenic.com/wiki/subrepos
The ldap developers could pull the main (+ nested) repo(s) (if they need
one),
projects could pull the sdk they need only :-)
b) Keep LDAP SDK development in CVS, snapshot LDAP SDK to Mercurial.
This would mean status-quo for the LDAP SDK developers.
Yes, the basic "need" of c-c would be a c-sdk only hg (mirror) repo.
(Could be the true c-sdk repo (see above), or a mirror repo managed by
either the directory team or the mailnews one if need be...)
For comm-central I would recommend going for the importing the source of
a specific tagged version directly into comm-central
That would be the simpliest way.
Yet, I'm not sure I like it:
*No more 'client.py --skip-ldap', though I guess it's rarely used.
*Probably no history between the imported versions.
*Newer checkins not imported so much harder to use the import to
contribute to c-sdk.
I think managing a separate (c-sdk only) (mirror) repo would not be
really harder and have more uses than importing into c-c.
_______________________________________________
dev-tech-ldap mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-ldap
