Re: Splitting the repos...

This has been my experience with multi-repo projects (most recently
Rust) as well.

Patrick Cloke wrote:
> Gary,
> 
> First off I'll say that splitting this out would like making building
> libpurple for Instantbird easier, so that'd be nice...
> 
> It might make development harder, however. This is from my experiences
> developing on Instantbird which has components across 3 repositories:
> mozilla-central (UI core, networking, security, etc. from Firefox),
> comm-central (Instantbird and Thunderbird code), purplexpcom (libpurple
> and XPCOM interfaces to libpurple):
> 
>   * It is significantly more difficult to get new people set-up if they
>     need to pull multiple repositories and can be more confusing to
>     explain things.
>   * Mass changes over multiple repositories can become harder (e.g.
>     renaming things, changing the build system, etc.).
>   * Building can become more frustrating: you need to ensure you have
>     corresponding revisions of both repositories that build together.
>   * People might update a single repository and forget to update others
>     (e.g. a Finch developer might make changes to Finch and
>     corresponding libpurple changes; but not update Pidgin for those
>     same changes).
> 
> I've also tried to run separate repositories in work environments in
> various environments (usually based on Git)...I've found they always
> fail miserably. (Keeping versions in sync without real rules and
> interfaces is a huge pain.) Things like git submodules/Mercurial
> sub-repos make this a little easier by pointing to a known "working
> revision", but then make it difficult to work on the bleeding edge
> (tip/master) in these systems.
> 
> Some of the big companies, e.g. Facebook, use a single repository:
> 
>     "Our code base has grown organically and its internal dependencies
>     are very complex. We could have spent a lot of time making it more
>     modular in a way that would be friendly to a source control tool,
>     but there are a number of benefits to using a single repository.
>     Even at our current scale, we often make large changes throughout
>     our code base, and having a single repository is useful for
>     continuous modernization. Splitting it up would make large, atomic
>     refactorings more difficult. On top of that, the idea that the
>     scaling constraints of our source control system should dictate our
>     code structure just doesn't sit well with us." -- Durham Goode,
>     Siddharth P Agarwal
>     https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
> 
> 
> I think that Google also does this
> (http://programmers.stackexchange.com/questions/41435/what-is-googles-repository-like).
> 
> Overall I'd say: think very carefully about why you're doing this and if
> it will really help anything. If you plan to do this, invest in some
> tooling around it (e.g. make it easy to update to compatible versions of
> all repositories without thinking much).
> 
> --Patrick
> 
> On 4/7/16 10:19 AM, Gary Kramlich wrote:
> > This has been brought up in [email protected]
> > <mailto:[email protected]> recently and I'd like to actually
> > discuss it here where everyone can see it.  I've been waiting to bring
> > it up until I had more of the CI stuff setup, but now is as good of a
> > time as any.
> >
> > As you may or may not know, I strongly support splitting the repo into
> > libpurple, pidgin, libgnt, and finch repos.  I would also like to
> > split out some of our less commonly used protocol plugins (namely
> > meanwhile and zephyr) to separate repos to get the dependency and
> > build complexity down.
> >
> > For most developers, this means you'll have to build an libpurple and
> > or libgnt separately.  However, once all of the CI stuff is setup, if
> > you just want to work on pidgin or finch you shouldn't have to compile
> > libpurple and libgnt separately anymore since you can pull them out of
> > the CI artifacts.
> >
> > At any rate, discuss! :)
> >
> > Thanks,
> >
> > --
> > Gary Kramlich <[email protected] <mailto:[email protected]>>
> >
> >
> > _______________________________________________
> > Devel mailing list
> > [email protected]
> > https://pidgin.im/cgi-bin/mailman/listinfo/devel
> 

> _______________________________________________
> Devel mailing list
> [email protected]
> https://pidgin.im/cgi-bin/mailman/listinfo/devel

_______________________________________________
Devel mailing list
[email protected]
https://pidgin.im/cgi-bin/mailman/listinfo/devel