On 15 May 2013, at 17:33, Christian Gruber wrote:
> I'm about to declare frustration and just bulk export all the change in a big
> commit. I'm fighting with a regression problem that JavaMoe has whereby it
> digs through Change Lists / commits in order to determine equivalency between
> two repositories, and then attempts to see what has changed in each since
> then, and stages changes from one relative to the other in a fresh version
> control workspace. All that is fine, but the last chagnes that got into our
> workspace internally were the Pom bumping changes that I believe you added,
> Stuart.
Yes, if it helps with the sync'ing you can drop/back-out that commit - it's
only a few lines in a couple of files.
> That should be fine, but it means that we have all sorts of change _behind_
> the changes so its' having issues syncing.
>
> I was trying to push out something that would reflect each change in our
> repository so the external repo would have these changes one-at-a-time, but
> that is proving more than JavaMOE can handle in the current state of the
> repo(s). So I'm going to bulk-push a big change out today, which amounts to
> a diff between git and google-internal. I'll try to collect change
> information (commit logs) so at least WHAT changed is reflected.
>
> I do have Moe working well enough that once the two repos are in sync, as
> long as we do a regular sync before both repos stray too far from a common
> point, we should be fine. I'm sorry to have been so OCD about this - I was
> trying to keep the repos in good order for the open-source community, but at
> this point, a release is more important than repo cleanliness. :/
Sounds good - once the repos are in sync will there be a chance to suggest some
patches/fixes before you cut a release?
> Christian.
>
> On 15 May 2013, at 6:02, Stuart McCulloch wrote:
>
>> Any news? I'm willing to help out where needed...
>>
>> On 18 Apr 2013, at 20:29, Christian Gruber wrote:
>>> 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.
>>>
>>>
>>
>> --
>> 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.
>
>
--
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.
