tech-repository archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: src and xsrc merge proposal



Kamil Rytarowski <n54%gmx.com@localhost> writes:

> I propose to merge src and xsrc into a single source tree.

It is of course not  possible  to have a full evaluation without a
precise plan, and thus not possible to achieve the required consensus.

I think it's really obvious that any such decision must be formally
adopted by core, rather than any developer doing it after perceiving
consensus.

> Rationale:
>
>  - xsrc (0.9GB) is around 22.5% of size of src+xsrc (4GB), which is
> still significant but hardly important enough to maintain the split.
>  - xsrc is not restricted to Xorg these days and ships libraries for at
> least Wayland.
>  - It is cost to maintain build machinery for two repositories that can
> be desynced.
>  - Easier to analyze repository changes without looking intwo two
> distinct repositories.
>  - After recent Andrew Doran's SMP improvements, in my personal feeling
> DVCS perform well in large repositories now.
>  - We could rename the src repository to netbsd and merge CVS history of
> src and xsrc in one tree(*). This is a request from certain developers
> and I find it valuable.
>
> There is an option to preserve xsrc's history and merge it into src/ or
> reset it (redirecting to an archived xsrc tree) and import freshly into
> src/. It is hard (impossible without rewriting older branches?) to merge
> history without confusing developers and breaking older snapshots and
> this is why I am proposing to reset it and freshly import into src/.

I think this overstates the trouble of the two repositories and
underestimates the trouble of combining them.  In my experience, grand
changes are almost always more difficult than expected.

I don't think losing history is a good tradeoff for this.

If xsrc were to just become a subdirectory of src, that wouldn't be so
bad.   Aside from a few path adjustments, it would be as before, execpt
branching/tagging checkouts would be over both.

However, I really don't find it hard to update both trees to the same
tag/etc.   Are you really having trouble doing two diffs instead of one
for the entire system?   Wrapper script?

It seems there is a culture of git submodules for large things, so it's
not clear a monolithic repository is an obvious goal.  (I'm not speaking
in favor of submodules, just pointing out that some do that.)

Given all this, I think it's best to let this be as it is.



Home | Main Index | Thread Index | Old Index