Mark Banner wrote:
On 27/07/2009 17:25, Rich Megginson wrote:
Moving to Mercurial is fine with me. I've been using git now for quite
some time and have really grown to like how much better it is than CVS.
I understand hg is similar to git. As far as the repo layout, it doesn't
matter to me if the c-sdk has its own top level repo or is part of a
larger repo, as long as it is easy to
1) checkout just the c-sdk
hg clone http://hg.mozilla.org/whatever/it/is
Ok, good.
2) build just the c-sdk
As normal ;-)
heh
3) tag individual and separate c-sdk releases
hg tag -r <changeset> MY_TAG
Would this tag the entire repo, or just the c-sdk portion? Or does it
really matter? I know with git, tags are cheap and easy to manage, so
it doesn't really matter.
I'm not quite sure what you mean by separate c-sdk releases.
If it doesn't matter that non-c-sdk code will be tagged with a c-sdk
release tag, then it doesn't matter if the c-sdk repo is completely
separate.
4) produce individual source code releases of the c-sdk
You can:
hg clone ....
hg update -r MY_TAG
Then you could zip it up, which would include the history, or I expect
we could probably copy one of the source tar ball commands from the
mozilla-central/comm-central build systems that would get you just the
source files.
With git, I can use the git archive command to produce a source tarball
from a specific tag or changeset (commit). But I think that archives
the entire repository, not a subdirectory. If that's not possible, then
we can just use clone and update to get the local source repo in the
right state, then just use tar directly against the source repo.
Rich, so are you saying you would be happy to split the different SDKs
across repositories? Or would you prefer them all in one?
For the perl and java sdks, they can be separate, since (afaik) no other
mozilla component uses them. For the c-sdk, as long as we can preserve
the ability to develop and make c-sdk releases independent of
t-bird/seamonkey, if it makes life easier for t-bird/seamonkey
developers to have the code embedded in their larger source code
repositories, I think that would be fine.
The only thing I can think of with having them all-in-one is that one
tag would tag all the files in the repository, but I guess that isn't
really an issue.
As long as tags are cheap and easy to manage, which I'm assuming they
are with hg.
From a comm-central view point I think we could cope with either,
although if we did an all-in-one I'd probably think about moving the
xpcom sdk back to the LDAP repository as that would also help building
binary extensions against xulrunner with LDAP.
Mark.
_______________________________________________
dev-tech-ldap mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-ldap
