A few posts here and in the other thread have mentioned abstracting away complexity to servers as if it is a magical solution that makes all problems go away.
Yes, deploying a server-side solution to do some "syncing" is doable and solves a subset of notable problems. But I advise extreme caution against asserting simplicity for anything. One of the large shifts that we're starting to see take place for Firefox tooling are the breakdown of the barriers between a) the build system and version control b) the build system and automation. Transitively, we're seeing all 3 of these things (which are easy to mentally model as independent concepts) start to merge. This is both terrifying and exciting. I really owe a blog post or gdoc or something on this topic, but essentially we're at a few tipping points in terms of scale where we need tighter cohesion between these systems to continue to scale in a way that meets developers' needs. Artifact builds are an example of such a system. Automation builds these artifacts and indexes against the version control revision (currently Mercurial). The build system ties it all together. In order to use an artifact build locally, you need to find an artifact build from automation. This means knowing the indexed version control revision. With git-cinnabar, the commit map is locally known (read: fast and well-defined). With vanilla Git, that commit map is... not local. (Yes, we could work our way out of this commit mapping problem using various mechanisms (notably caching and/or content-based hashing for indexing). But there is no obvious solution at this time.) Artifact builds are only the tip of the iceberg for this class of problem. In 2-4 years I see us in a position where version control, the build system, and automation function as one logical system working in harmony. We're still in the early stages of this shift, which is probably why you haven't noticed it. Therefore, decisions and policies around how to support version control today thus incur a magnitude more effort to support down the road (and even then may result in poorer outcomes for the user base not on the "primary" set of tools). I'm particularly sensitive to the butterfly effect on this (likely inevitable) transition and I don't want to hamstring future productivity efforts by committing us to a short-sighted version control support policy that won't easily scale. That being said, I think a canonical git-cinnabar repository might be doable. I view that as a glorified cache to offload the expensive first-time conversion. But using it with vanilla Git is a bit more concerning from a future compatibility perspective, so we should set expectations for appropriate use accordingly. On Mon, Sep 18, 2017 at 8:59 AM, Nicholas Hurley <hur...@mozilla.com> wrote: > I've had quite a few times (every time I get a new machine) that I've had > issues with git-cinnabar and multiple machines. This has resulted in me > just scp'ing my entire repo every time I get a new machine (which comes > with its own set of issues... messed up paths in the .git/config, for > example). I grant that some of this is due to my own stupidity, but aren't > tools supposed to make it harder for one's own stupidity to get in the way? > > I haven't even tried to share anything with anyone else via git, I just > send them a patch. The chance of mismatched sha's is Too Damn High! This > is, as the saying goes, suboptimal. > > All this to say, I think having an official cinnabar repo (preferably with > cinnabar metadata I can fetch, too) would make things significantly easier > for a lot of use-cases, and I can't think of a single use-case that it > would make things worse for over the long-term (ie, once we have autoland > everywhere and no manual pushes to m-c or try). The initial fetch might > take a while if we include metadata, but that's a one-time (per machine) > cost. > > Even better would be the "all the magic happens server-side" solution. Then > I could Just Use Git, and never have to worry about any of this junk ever > again. > > On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight <amccrei...@mozilla.com> > wrote: > > > On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta <kgu...@mozilla.com> > > wrote: > > > > > I've tried using cinnabar a couple of times now and the last time I > > > tried, this was the dealbreaker for me. My worfklow often involves > > > moving a branch from one machine to another and the extra hassle that > > > results from mismatched SHAs makes it much more complicated than it > > > needs to be. gecko-dev doesn't have this problem as it has a canonical > > > upstream that works much more like a regular git user expects. > > > > > > > For what it is worth, I regularly pull from one machine to another with > > git-cinnabar, and it works just fine without any problems from mismatched > > SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has > been > > totally transparent. > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
