[PATCH] D24167: Moving to GitHub - Unified Proposal

[Chris Bieneman via llvm-commits]

beanz added inline comments.


> mehdi_amini wrote in GitHubMove.rst:249
> > The automation will run. It will collect a list of commits that have been pushed to each repository since the last time the script ran.
> 
> Atomically?
> 
> > There is no race condition that I see.
> 
> Did you read my sequence 1-7 that describes an example of race?
> 
> > but I see no reason why it cannot be as robust as the single-project mirrors that the mono-repo proposal includes.
> 
> Define "robust". The single-project mirrors have a very well *deterministic* algorithm to construct, and reconstruct them at will, you don't have one for the multi-repo. That's not "robust" to me.

I've updated my automation (https://github.com/llvm-beanz/llvm-submodules) to make one umbrella commit per commit to sub-project repository. This has a single commit granularity. That was the original point I was arguing. It works. It is done.

Is it perfect? No. There are a number of situations where the order of the commits to the submodule can be impacted by the order and proximity of commits to the project repositories. That is irrelevant to the point I was making. I'm more than happy to debate with you about whether or not that matters, but that is a separate issue from what I was pointing out.

Do we need to belabor this further, or will you update the document based on my feedback?

> mehdi_amini wrote in GitHubMove.rst:207
> > That is 'making easier' not 'encouraging'.
> 
> "All the source is there //by default//"  *+* "making it easier" => why I wrote "encouraging".
> 
> > Personally I fall to 'grep' way before I fall to 'git grep' for things like this, and I don't think the monorepo has any enforcement of this.
> 
> Not sure why "enforcement" comes into play here?

> "All the source is there by default"

This is what makes it easier. Your math is double counting it. I disagree with your wording here. I've told you I disagree. You can continue to disregard my feedback or you can fix it. The choice is yours.

> mehdi_amini wrote in GitHubMove.rst:214
> So do you have anything *concrete* that could be added here, be practical (something we'd be willing to encourage in the future),  be understandable by any dev, *and* not take > 20 lines to describe?

You gave an example that is factually incorrect. I'm asking you to fix it. That is concrete. In my earlier comment I told you why your example was incorrect. You can remove the example, or come up with an alternative. That is your choice. What you cannot do, is use this factually inaccurate example.

> mehdi_amini wrote in GitHubMove.rst:350
> That'd make a long list, how should it be presented?

However you think it is best presented. A table would seem fitting. You could put it below and have a link down to it. I think that if you're bringing size into the discussion you need to provide sufficient data.

> mehdi_amini wrote in GitHubMove.rst:445
> Are you sure that this command does what you think it does?
> If I read correctly the doc, it is looking at your *reflog*, not the history.
> 
> The right one should be something like `git checkout ```git rev-list -n 1 --before="2009-07-27 13:37" master``
> 
> > I just think it is worth noting under the multi-repo proposal that timestamp based checkouts are expected to work due to the linear history requirement, which means you don't need the submodule repo.
> 
> OK that wasn't clear to me the first time.

You are correct, you need to use `rev-list` to get the commit hash.

> mehdi_amini wrote in GitHubMove.rst:601
> I'm still missing what would be similar for someone integrating multiple projects from SVN today (assuming such downstream integrator exists) with the multi-repo?

I strongly suspect that very few users are using a single SVN checkout that contains more than one sub-project. If you discount that workflow, the workflow for interfacing using the GitHub SVN bridge is very similar whether you are using one repo or many.

Additionally, with the mono repo the combined SVN workflow is actually a lot better than with SVN today. It is way less fragile since you aren't doing sub-directory checkouts. This means you don't run the risk of inadvertently running `svn up` and pulling down way more than you wanted.

https://reviews.llvm.org/D24167