What Sam said… and…
we have to map a project's internal directory structure but also
repository kind and the directory structure around projects.
Imagine you have an SVN repo and a git repo. The svn repo had, say,
this structure and a build system that had build files close to the
code:
${repo_root}/projects/project{1,2,3}/sources/some/package/build_file
${repo_root}/projects/project{1,2,3}/sources/some/package/MyCode.java
but you were open-sourcing project1 in its own git repo at
${new_repo_root}/build.xml
${new_repo_root}/some/package/MyCode.java
You can't just replay commits. You have to replay commits while
simultaneously mapping directories around the projects, as well as
within the project. You also have to scrub in both directions so
the tool doesn't suck in changes to build.xml about which you may
or may not internally care, while similarly ignoring build_file in
the other direction. You may also want to scrub out internal-only
code, etc.
(Guava also strips out anything with @GwtIncompatible when we
generate our GWT-compatible sources so we can maintain fewer
sources in duplicate form, though that's not an issue we tackle in
Guice)
(A version of) the syncing system we use is here
(https://code.google.com/p/moe-java/) though it is maintained by
volunteers only. The format has idiosyncrasies and all the experts
were very busy remaking the universe in their day jobs.
It really is kind of awesome black magic. Dan Bentley and Yash
Parghi are wizards. But for a company to sync two source code bases
that are disparate in structure, it's a life-saver (well, ok… a
day-job time-saver).
cheers,
Christian.
On 17 Apr 2013, at 4:59, Sam Berlin wrote:
It's mostly just the directory structures are pretty different. MOE
makes
it all magically happen, so we've been banking on using the newer
version
of that... It just took a while to figure out the right incantation
to make
it happy. Now that Christian's figured it out, things should be
smooth
again.
sam
On Apr 17, 2013 7:24 AM, "Tim Boudreau" [email protected] wrote:
On Wed, Apr 17, 2013 at 1:05 AM, Christian Gruber
[email protected]:
I'm now unblocked on where I was blocked earlier trying to get our
syncing tool to work between the internal google repository and the
code
site repository.
Having set up and also rebuilt from the ground up a lot of build
systems
over recent years, you've got me curious - what are you guys doing
internally that makes this hard? I know large organizations have
their
processes and codebases have their history (I worked for Sun, after
all!).
But I've got to say, if it takes months to build a diff and apply
it, the
reason why must be pretty interesting.
-Tim
You received this message because you are subscribed to the Google
Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to [email protected].
To post to this group, send email to [email protected].
Visit this group at
http://groups.google.com/group/google-guice?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
You received this message because you are subscribed to the Google
Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at
http://groups.google.com/group/google-guice?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Christian Gruber :: Google, Inc. :: Java Core Libraries ::
Dependency Injection
email: [email protected] :::: mobile: +1 (646) 807-9839
--
You received this message because you are subscribed to the Google
Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at
http://groups.google.com/group/google-guice?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
