Mailing List Archive

Mirroring the later 8.x release tags in the "new" split repositories
Hello all,

As mentioned in SOLR-15874
<https://issues.apache.org/jira/browse/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.

Eventually once Solr is on 10.x, there will be very little need for the
lucene-solr repository, since Lucene has already moved on past 8.x. At that
point, having all the previous release tags in the new repos will make it
possible to remove the lucene-solr repo. (Although that is not something I
want to discuss on this thread, just merely one reason hosting the tags is
a good idea)

I'm happy to mirror the tags to each repository manually, unless anyone has
objections (for either lucene or solr).

- Houston
Re: Mirroring the later 8.x release tags in the "new" split repositories [ In reply to ]
I think mirroring the tags is a good idea and can only be useful.

On Tue, Jan 4, 2022 at 8:56 AM Houston Putman <houston@apache.org> wrote:

> Hello all,
>
> As mentioned in SOLR-15874
> <https://issues.apache.org/jira/browse/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.
>
> Eventually once Solr is on 10.x, there will be very little need for the
> lucene-solr repository, since Lucene has already moved on past 8.x. At that
> point, having all the previous release tags in the new repos will make it
> possible to remove the lucene-solr repo. (Although that is not something I
> want to discuss on this thread, just merely one reason hosting the tags is
> a good idea)
>
> I'm happy to mirror the tags to each repository manually, unless anyone
> has objections (for either lucene or solr).
>
> - Houston
>


--
Anshum Gupta
Re: Mirroring the later 8.x release tags in the "new" split repositories [ In reply to ]
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Mirroring the later 8.x release tags in the "new" split repositories [ In reply to ]
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 <dawid.weiss@gmail.com> 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: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Mirroring the later 8.x release tags in the "new" split repositories [ In reply to ]
> 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 <houston@apache.org> 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 <dawid.weiss@gmail.com> 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: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Mirroring the later 8.x release tags in the "new" split repositories [ In reply to ]
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 <jan.asf@cominvent.com> 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 <dawid.weiss@gmail.com>:
> >
> > ?
> >>
> >> 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 <houston@apache.org>
> 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 <dawid.weiss@gmail.com>
> 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: dev-unsubscribe@solr.apache.org
> >>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Mirroring the later 8.x release tags in the "new" split repositories [ In reply to ]
+1 to Houston's proposal. Given all the release tags seen here:
https://github.com/apache/solr/tags it makes sense that it would include
the tag for 8.11 and the others we're missing. I think this is a really
easy decision as it's weird/inconsistent that these particular versions are
omitted yet the many older ones exist.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Tue, Jan 4, 2022 at 4:01 PM Houston Putman <houston@apache.org> wrote:

> 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 <jan.asf@cominvent.com> 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 <dawid.weiss@gmail.com>:
>> >
>> > ?
>> >>
>> >> 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 <houston@apache.org>
>> 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 <dawid.weiss@gmail.com>
>> 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: dev-unsubscribe@solr.apache.org
>> >>> For additional commands, e-mail: dev-help@solr.apache.org
>> >>>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> > For additional commands, e-mail: dev-help@solr.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>
>>
Re: Mirroring the later 8.x release tags in the "new" split repositories [ In reply to ]
> I did mean that we should be pushing the tags as well as their associated
> commits.
>

You can even edit them by hand so you can definitely have references
pointing at void...

I already expressed my opinion on the matter but I won't object if you wish
to do it. The problem I see is that it's really easy to break things in a
catastrophic way by force-pushing refs or by pushing refs that shouldn't be
copied - it's not hard, but it's easy to make a mistake. I'd try out ten
times on a bare test clone somewhere before actually doing it on the target
git repository.

But it is definitely doable. Git repositories are conceptually very simple
- just a graph of commits and tags/ labels.

Dawid
RE: Mirroring the later 8.x release tags in the "new" split repositories [ In reply to ]
I agree with Dawid, why the hell do we need those tags? The old lucene-solr repo can stay forever on Github. If I want to checkout an older version, I would go into the old repo and check it out. In fact that’s also what tools may do, because the old git repo is stated in the pom.xml files (or similar).



I would rather go and nuke the tags (not the commits of course) from new repo for everything before 9.



Uwe



-----

Uwe Schindler

Achterdiek 19, D-28357 Bremen

<https://www.thetaphi.de> https://www.thetaphi.de

eMail: uwe@thetaphi.de



From: Dawid Weiss <dawid.weiss@gmail.com>
Sent: Wednesday, January 5, 2022 8:17 AM
To: Lucene Dev <dev@lucene.apache.org>
Cc: Solr Dev <dev@solr.apache.org>
Subject: Re: Mirroring the later 8.x release tags in the "new" split repositories





I did mean that we should be pushing the tags as well as their associated commits.



You can even edit them by hand so you can definitely have references pointing at void...



I already expressed my opinion on the matter but I won't object if you wish to do it. The problem I see is that it's really easy to break things in a catastrophic way by force-pushing refs or by pushing refs that shouldn't be copied - it's not hard, but it's easy to make a mistake. I'd try out ten times on a bare test clone somewhere before actually doing it on the target git repository.



But it is definitely doable. Git repositories are conceptually very simple - just a graph of commits and tags/ labels.



Dawid
Re: Mirroring the later 8.x release tags in the "new" split repositories [ In reply to ]
Perhaps an alternative would be to create an identical set of tags pointing
at a single commit which would contain a plain text file delegating you to
where the code for these tags actually is (different repository)? :) Hell,
you could even set up a submodule (to the shared repository) inside new
repositories and point the submodule at the exact same tag...

All this is fun to consider but I still see no point of actually spending
any time on such workarounds.

D.

On Thu, Jan 6, 2022 at 2:47 PM Uwe Schindler <uwe@thetaphi.de> wrote:

> I agree with Dawid, why the hell do we need those tags? The old
> lucene-solr repo can stay forever on Github. If I want to checkout an older
> version, I would go into the old repo and check it out. In fact that’s
> also what tools may do, because the old git repo is stated in the pom.xml
> files (or similar).
>
>
>
> I would rather go and nuke the tags (not the commits of course) from new
> repo for everything before 9.
>
>
>
> Uwe
>
>
>
> -----
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: uwe@thetaphi.de
>
>
>
> *From:* Dawid Weiss <dawid.weiss@gmail.com>
> *Sent:* Wednesday, January 5, 2022 8:17 AM
> *To:* Lucene Dev <dev@lucene.apache.org>
> *Cc:* Solr Dev <dev@solr.apache.org>
> *Subject:* Re: Mirroring the later 8.x release tags in the "new" split
> repositories
>
>
>
>
>
> I did mean that we should be pushing the tags as well as their associated
> commits.
>
>
>
> You can even edit them by hand so you can definitely have references
> pointing at void...
>
>
>
> I already expressed my opinion on the matter but I won't object if you
> wish to do it. The problem I see is that it's really easy to break things
> in a catastrophic way by force-pushing refs or by pushing refs that
> shouldn't be copied - it's not hard, but it's easy to make a mistake. I'd
> try out ten times on a bare test clone somewhere before actually doing it
> on the target git repository.
>
>
>
> But it is definitely doable. Git repositories are conceptually very simple
> - just a graph of commits and tags/ labels.
>
>
>
> Dawid
>