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]>wrote:
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.
