Dawid, I did mean that we should be pushing the tags as well as their associated commits. I was unaware that you could push the tags without the commits, sorry if I caused confusion there.
Jan, Looking in the diff between the "history/branches/lucene-solr/branch_8x" tag in apache/solr and the current "branch_8_11" in apache/lucene-solr, there is around 12 MB of commits to add. This is a rough estimate, but it should be close enough. The best approximation I have of the apache solr repository is that it's size is around 400 MB. So adding these tags/refs would cause a 3% increase in the size of the repo. The lucene repo is a little larger currently, but the new tag sizes should be identical. - Houston On Tue, Jan 4, 2022 at 3:36 PM Jan Høydahl <[email protected]> wrote: > We have edit history ever since the earliest svn commits, we just lack a > years worth of commits from the latest 8.x versions, so from a traceability > view it makes sense, instead of having to look in two repos. Do you know > how much weight it will add to a full clone? > > Jan Høydahl > > > 4. jan. 2022 kl. 21:01 skrev Dawid Weiss <[email protected]>: > > > > > >> > >> You can push a tag to a repo that doesn't already have that commit (or > history of commits) > > in an existing branch, without issue. > > > > But why do it? These are refs - if they point to non-existing commits > > then I honestly don't see any value in having them. It would > > confuse the hell out of me. > > > >> They are separate projects, but with a shared history. I'd like to be > able to go to the apache/solr github > > and be able to go through the history of a file in different release > > versions, even if that specific release happened > > under apache/lucene-solr. > > > > This is a different requirement, actually. If Solr (or Lucene) would > > like to keep such a history then I think it should just fetch those > > release refs and all the commits leading to them. Since these projects > > share a common root, there is nothing to prevent this from happening. > > Then tags point at actual revisions and everything makes sense. > > > > This does not change the fact that I don't really see much value in > > doing all this. > > > > Dawid > > > >> On Tue, Jan 4, 2022 at 8:30 PM Houston Putman <[email protected]> > wrote: > >> > >> They don't have those commits, but they also don't have the commits for > the > >> previous release tags in the repo. You can go to any of the release > tags, choose > >> a commit to view and you will get a message saying: > >> > >>> > >>> This commit does not belong to any branch on this repository, > >>> and may belong to a fork outside of the repository. > >> > >> > >> You can push a tag to a repo that doesn't already have that commit (or > history of commits) > >> in an existing branch, without issue. > >> > >> They are separate projects, but with a shared history. I'd like to be > able to go to the apache/solr github > >> and be able to go through the history of a file in different release > versions, even if that specific release happened > >> under apache/lucene-solr. > >> > >> - Houston > >> > >>> On Tue, Jan 4, 2022 at 2:02 PM Dawid Weiss <[email protected]> > wrote: > >>> > >>>> As mentioned in SOLR-15874, we are not hosting the tags for the > latest 8.x releases in the split apache/solr and apache/lucene > repositories. All release tags made prior to the repository split exist in > the new repos, so I see no reason that the newer 8.x tags cannot exist in > the new repos as well. > >>> > >>> I'm not sure I understand - to create a tag you'd need that particular > >>> commit - the "new" repositories for each project don't have those > >>> commits (and arguably shouldn't have since they're, well, separate > >>> projects now). > >>> > >>> Dawid > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
