Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Portage Git migration - clean cut or git-cvsserver

 

 

First page Previous page 1 2 3 4 5 6 7 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded


xmw at gentoo

May 23, 2012, 5:42 AM

Post #1 of 163 (1312 views)
Permalink
Portage Git migration - clean cut or git-cvsserver

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

i've looked at the blockers of "[TRACKER] portage migration to git"
[1] and want to discuss "testing git-cvsserver" [2].

There are two proposed scenarios how to migrate the developers write
access to the portage tree.

"Clean cut" turns of cvs access on a given and announced timestamp,
rsync-generation/updates is suspended (no input -> no changes), some
magic scripts prepare the git repo (according to [3], some hours
duration) and we all checkout the tree (might be some funny massive load).

"testing git-cvsserver" proses "Clean cut" with the additional ability
to continue using cvs update/commit, - in best case - on the old
checkout w/o alteration on the developers side.

"Clean cut" forces us to clean up out dirty checkouts (I have some
added directories, added ebuilds i hesitated to `repoman commit`).
Plus we have to alter all our hot-wired portage mangling scripts from
cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
checkout + egencache for checkout) and have an automated google-chrome
bump script). But this can be accomplished on a per developer basis,
and slackers don't stall the process.

"testing git-cvsserver" forces us all to test these cvs'ish scripts
and behaviours against a git-cvsserver and report.
We all know that this test-runs will never happen, stalling this bug
till infinity.
Plus infra/"subset of devs marshalling the migration" get stuck
between fixing git issues and git-cvsserver.

*if you still read this* *wow*

Please discuss my arguments and come to the conclusions to
RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
this bug from the blockers of "[TRACKER] portage migration to git".

My lengthy 2 cents.

[1] https://bugs.gentoo.org/333531
[2] https://bugs.gentoo.org/333699
[3] https://bugs.gentoo.org/333705#c2
- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
=jXLQ
-----END PGP SIGNATURE-----


johu at gentoo

May 23, 2012, 5:54 AM

Post #2 of 163 (1280 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
> i've looked at the blockers of "[TRACKER] portage migration to git"
> [1] and want to discuss "testing git-cvsserver" [2].
>
> There are two proposed scenarios how to migrate the developers write
> access to the portage tree.
>
> "Clean cut" turns of cvs access on a given and announced timestamp,
> rsync-generation/updates is suspended (no input -> no changes), some
> magic scripts prepare the git repo (according to [3], some hours
> duration) and we all checkout the tree (might be some funny massive load).
>
> "testing git-cvsserver" proses "Clean cut" with the additional ability
> to continue using cvs update/commit, - in best case - on the old
> checkout w/o alteration on the developers side.
>
> "Clean cut" forces us to clean up out dirty checkouts (I have some
> added directories, added ebuilds i hesitated to `repoman commit`).
> Plus we have to alter all our hot-wired portage mangling scripts from
> cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
> checkout + egencache for checkout) and have an automated google-chrome
> bump script). But this can be accomplished on a per developer basis,
> and slackers don't stall the process.
>
> "testing git-cvsserver" forces us all to test these cvs'ish scripts
> and behaviours against a git-cvsserver and report.
> We all know that this test-runs will never happen, stalling this bug
> till infinity.
> Plus infra/"subset of devs marshalling the migration" get stuck
> between fixing git issues and git-cvsserver.
>
> *if you still read this* *wow*
>
> Please discuss my arguments and come to the conclusions to
> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> this bug from the blockers of "[TRACKER] portage migration to git".
>
> My lengthy 2 cents.
>
> [1] https://bugs.gentoo.org/333531
> [2] https://bugs.gentoo.org/333699
> [3] https://bugs.gentoo.org/333705#c2
> - --
> Gentoo Dev
> http://xmw.de/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
> VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
> =jXLQ
> -----END PGP SIGNATURE-----

I support RESOLUTION WONTFIX, if nobody cares about the bug since it was
opened it is obvious out of interest. There is no reason to support jurassic
software.

Clean cut++

Cheers
--
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD
Attachments: signature.asc (0.48 KB)


thev00d00 at gentoo

May 23, 2012, 6:14 AM

Post #3 of 163 (1280 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On May 23, 2012 1:55 PM, "Johannes Huber" <johu [at] gentoo> wrote:
>
> Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
>
> > Hash: SHA256
>
> >
>
> > Hi,
>
> >
>
> > i've looked at the blockers of "[TRACKER] portage migration to git"
>
> > [1] and want to discuss "testing git-cvsserver" [2].
>
> >
>
> > There are two proposed scenarios how to migrate the developers write
>
> > access to the portage tree.
>
> >
>
> > "Clean cut" turns of cvs access on a given and announced timestamp,
>
> > rsync-generation/updates is suspended (no input -> no changes), some
>
> > magic scripts prepare the git repo (according to [3], some hours
>
> > duration) and we all checkout the tree (might be some funny massive
load).
>
> >
>
> > "testing git-cvsserver" proses "Clean cut" with the additional ability
>
> > to continue using cvs update/commit, - in best case - on the old
>
> > checkout w/o alteration on the developers side.
>
> >
>
> > "Clean cut" forces us to clean up out dirty checkouts (I have some
>
> > added directories, added ebuilds i hesitated to `repoman commit`).
>
> > Plus we have to alter all our hot-wired portage mangling scripts from
>
> > cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
>
> > checkout + egencache for checkout) and have an automated google-chrome
>
> > bump script). But this can be accomplished on a per developer basis,
>
> > and slackers don't stall the process.
>
> >
>
> > "testing git-cvsserver" forces us all to test these cvs'ish scripts
>
> > and behaviours against a git-cvsserver and report.
>
> > We all know that this test-runs will never happen, stalling this bug
>
> > till infinity.
>
> > Plus infra/"subset of devs marshalling the migration" get stuck
>
> > between fixing git issues and git-cvsserver.
>
> >
>
> > *if you still read this* *wow*
>
> >
>
> > Please discuss my arguments and come to the conclusions to
>
> > RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
>
> > this bug from the blockers of "[TRACKER] portage migration to git".
>
> >
>
> > My lengthy 2 cents.
>
> >
>
> > [1] https://bugs.gentoo.org/333531
>
> > [2] https://bugs.gentoo.org/333699
>
> > [3] https://bugs.gentoo.org/333705#c2
>
> > - --
>
> > Gentoo Dev
>
> > http://xmw.de/
>
> > -----BEGIN PGP SIGNATURE-----
>
> > Version: GnuPG v2.0.17 (GNU/Linux)
>
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> >
>
> > iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
>
> > VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
>
> > =jXLQ
>
> > -----END PGP SIGNATURE-----
>
>
>
> I support RESOLUTION WONTFIX, if nobody cares about the bug since it was
opened it is obvious out of interest. There is no reason to support
jurassic software.
>
>
>
> Clean cut++
>
>
>
> Cheers
>
> --
>
> Johannes Huber (johu)
>
> Gentoo Linux Developer / KDE Team
>
> GPG Key ID F3CFD2BD
>
>

Another vote for clean cut from me.


dilfridge at gentoo

May 23, 2012, 6:25 AM

Post #4 of 163 (1283 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

>
> Please discuss my arguments and come to the conclusions to
> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> this bug from the blockers of "[TRACKER] portage migration to git".
>

+1

Please cut cvs support once and for all.

--
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing
Attachments: signature.asc (0.82 KB)


titanofold at gentoo

May 23, 2012, 6:28 AM

Post #5 of 163 (1284 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/23/2012 09:25 AM, Andreas K. Huettel wrote:
>
>>
>> Please discuss my arguments and come to the conclusions to
>> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and
>> remove this bug from the blockers of "[TRACKER] portage migration
>> to git".
>>
>
> +1
>
> Please cut cvs support once and for all.
>
+1 for clean cut
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+85e4ACgkQVxOqA9G7/aDWpgD/SYfC3aOlOP2kAwK3qt81smH8
YWs60Kl77Xx+wIM1jx8A/0PkisxPTsLE5jR59GhaDmC+epoodW1GOak//pAvCmCG
=F8Rw
-----END PGP SIGNATURE-----


prometheanfire at gentoo

May 23, 2012, 6:31 AM

Post #6 of 163 (1280 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On 05/23/2012 07:54 AM, Johannes Huber wrote:
> Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber:
> Hi,
>
> i've looked at the blockers of "[TRACKER] portage migration to git"
> [1] and want to discuss "testing git-cvsserver" [2].
>
> There are two proposed scenarios how to migrate the developers write
> access to the portage tree.
>
> "Clean cut" turns of cvs access on a given and announced timestamp,
> rsync-generation/updates is suspended (no input -> no changes), some
> magic scripts prepare the git repo (according to [3], some hours
> duration) and we all checkout the tree (might be some funny massive load).
>
> "testing git-cvsserver" proses "Clean cut" with the additional ability
> to continue using cvs update/commit, - in best case - on the old
> checkout w/o alteration on the developers side.
>
> "Clean cut" forces us to clean up out dirty checkouts (I have some
> added directories, added ebuilds i hesitated to `repoman commit`).
> Plus we have to alter all our hot-wired portage mangling scripts from
> cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
> checkout + egencache for checkout) and have an automated google-chrome
> bump script). But this can be accomplished on a per developer basis,
> and slackers don't stall the process.
>
> "testing git-cvsserver" forces us all to test these cvs'ish scripts
> and behaviours against a git-cvsserver and report.
> We all know that this test-runs will never happen, stalling this bug
> till infinity.
> Plus infra/"subset of devs marshalling the migration" get stuck
> between fixing git issues and git-cvsserver.
>
> *if you still read this* *wow*
>
> Please discuss my arguments and come to the conclusions to
> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> this bug from the blockers of "[TRACKER] portage migration to git".
>
> My lengthy 2 cents.
>
> [1] https://bugs.gentoo.org/333531
> [2] https://bugs.gentoo.org/333699
> [3] https://bugs.gentoo.org/333705#c2
>
> I support RESOLUTION WONTFIX, if nobody cares about the bug since it was
> opened it is obvious out of interest. There is no reason to support jurassic
> software.
>
> Clean cut++
>
> Cheers

clean-cut++

--
-- Matthew Thode (prometheanfire)
Attachments: signature.asc (0.88 KB)


lxnay at gentoo

May 23, 2012, 6:34 AM

Post #7 of 163 (1279 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

Please kill CVS with fire!
I've been waiting for this since 2009.

--
Fabio Erculiani


kensington at gentoo

May 23, 2012, 7:17 AM

Post #8 of 163 (1279 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On 2012-05-23 22:42, Michael Weber wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
> i've looked at the blockers of "[TRACKER] portage migration to git"
> [1] and want to discuss "testing git-cvsserver" [2].
>
> There are two proposed scenarios how to migrate the developers write
> access to the portage tree.
>
> "Clean cut" turns of cvs access on a given and announced timestamp,
> rsync-generation/updates is suspended (no input -> no changes), some
> magic scripts prepare the git repo (according to [3], some hours
> duration) and we all checkout the tree (might be some funny massive load).
>
> "testing git-cvsserver" proses "Clean cut" with the additional ability
> to continue using cvs update/commit, - in best case - on the old
> checkout w/o alteration on the developers side.
>
> "Clean cut" forces us to clean up out dirty checkouts (I have some
> added directories, added ebuilds i hesitated to `repoman commit`).
> Plus we have to alter all our hot-wired portage mangling scripts from
> cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs
> checkout + egencache for checkout) and have an automated google-chrome
> bump script). But this can be accomplished on a per developer basis,
> and slackers don't stall the process.
>
> "testing git-cvsserver" forces us all to test these cvs'ish scripts
> and behaviours against a git-cvsserver and report.
> We all know that this test-runs will never happen, stalling this bug
> till infinity.
> Plus infra/"subset of devs marshalling the migration" get stuck
> between fixing git issues and git-cvsserver.
>
> *if you still read this* *wow*
>
> Please discuss my arguments and come to the conclusions to
> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> this bug from the blockers of "[TRACKER] portage migration to git".
>
> My lengthy 2 cents.
>
> [1] https://bugs.gentoo.org/333531
> [2] https://bugs.gentoo.org/333699
> [3] https://bugs.gentoo.org/333705#c2
> - --
> Gentoo Dev
> http://xmw.de/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
> VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
> =jXLQ
> -----END PGP SIGNATURE-----
>
>
Another vote for clean cut.


alexxy at gentoo

May 23, 2012, 7:39 AM

Post #9 of 163 (1279 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

+1 for killing cvs


Johannes Huber писал 2012-05-23 15:54:
> Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>
>> Hash: SHA256
>
>>
>
>> Hi,
>
>>
>
>> i've looked at the blockers of "[TRACKER] portage migration to git"
>
>> [1] and want to discuss "testing git-cvsserver" [2].
>
>>
>
>> There are two proposed scenarios how to migrate the developers write
>
>
>> access to the portage tree.
>
>>
>
>> "Clean cut" turns of cvs access on a given and announced timestamp,
>
>> rsync-generation/updates is suspended (no input -> no changes), some
>
>
>> magic scripts prepare the git repo (according to [3], some hours
>
>> duration) and we all checkout the tree (might be some funny massive
> load).
>
>>
>
>> "testing git-cvsserver" proses "Clean cut" with the additional
> ability
>
>> to continue using cvs update/commit, - in best case - on the old
>
>> checkout w/o alteration on the developers side.
>
>>
>
>> "Clean cut" forces us to clean up out dirty checkouts (I have some
>
>> added directories, added ebuilds i hesitated to `repoman commit`).
>
>> Plus we have to alter all our hot-wired portage mangling scripts
> from
>
>> cvs'ish to git'ish (I use my read/write checkout as portage tree
> (cvs
>
>> checkout + egencache for checkout) and have an automated
> google-chrome
>
>> bump script). But this can be accomplished on a per developer basis,
>
>
>> and slackers don't stall the process.
>
>>
>
>> "testing git-cvsserver" forces us all to test these cvs'ish scripts
>
>> and behaviours against a git-cvsserver and report.
>
>> We all know that this test-runs will never happen, stalling this bug
>
>
>> till infinity.
>
>> Plus infra/"subset of devs marshalling the migration" get stuck
>
>> between fixing git issues and git-cvsserver.
>
>>
>
>> *if you still read this* *wow*
>
>>
>
>> Please discuss my arguments and come to the conclusions to
>
>> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
>
>
>> this bug from the blockers of "[TRACKER] portage migration to git".
>
>>
>
>> My lengthy 2 cents.
>
>>
>
>> [1] https://bugs.gentoo.org/333531
>
>> [2] https://bugs.gentoo.org/333699
>
>> [3] https://bugs.gentoo.org/333705#c2
>
>> - --
>
>> Gentoo Dev
>
>> http://xmw.de/
>
>> -----BEGIN PGP SIGNATURE-----
>
>> Version: GnuPG v2.0.17 (GNU/Linux)
>
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>>
>
>> iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd
>
>> VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW
>
>> =jXLQ
>
>> -----END PGP SIGNATURE-----
>
> I support RESOLUTION WONTFIX, if nobody cares about the bug since it
> was opened it is obvious out of interest. There is no reason to
> support jurassic software.
>
> Clean cut++
>
> Cheers

--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum [at] gmail
mailto:alexxy [at] gentoo
mailto:alexxy [at] omrb


blueness at gentoo

May 23, 2012, 7:43 AM

Post #10 of 163 (1279 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On 05/23/2012 10:39 AM, Alexey Shvetsov wrote:
> +1 for killing cvs
>
>

Looks like the bloodbath begins. I too am in favor of killing cvs.

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness [at] gentoo
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535


jlec at gentoo

May 23, 2012, 7:54 AM

Post #11 of 163 (1281 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On 23/05/12 14:42, Michael Weber wrote:

> Hi,
>
> i've looked at the blockers of "[TRACKER] portage migration to git"
> [1] and want to discuss "testing git-cvsserver" [2].
>
> There are two proposed scenarios how to migrate the developers write
> access to the portage tree.
>
> "Clean cut" turns of cvs access on a given and announced timestamp,


I want to see to it gone. +1
Attachments: signature.asc (0.29 KB)


slyfox at gentoo

May 23, 2012, 9:32 AM

Post #12 of 163 (1266 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1 for git switch.

git-cvsserver would make sense if it would be completely transparent
for cvs client. and it's not. so why bother setuping fragile things?

- --

Sergei
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk+9ETgACgkQcaHudmEf86pHTgCgh0lWhRz5VAf0N9xRPOE4gld3
IXIAn1Q9q7BSaIGZpiUHgATng2rBVBWZ
=vbwK
-----END PGP SIGNATURE-----


rich0 at gentoo

May 23, 2012, 9:33 AM

Post #13 of 163 (1272 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On Wed, May 23, 2012 at 10:43 AM, Anthony G. Basile <blueness [at] gentoo> wrote:
>
> Looks like the bloodbath begins. I too am in favor of killing cvs.

Please, let it die. I'll miss my scripts, but I'll gladly deal with
that over whatever breakage comes along every time some cvs plugin
messes up the tree, or we can't use some useful git feature because
cvs amazingly enough behaves like an scm invented 20 years ago.

Rich


mgorny at gentoo

May 23, 2012, 9:33 AM

Post #14 of 163 (1270 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On Wed, 23 May 2012 14:42:37 +0200
Michael Weber <xmw [at] gentoo> wrote:

> *if you still read this* *wow*
>
> Please discuss my arguments and come to the conclusions to
> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
> this bug from the blockers of "[TRACKER] portage migration to git".

Kill it! And while we're at it, kill ChangeLogs as well!

/me hides...

--
Best regards,
Michał Górny
Attachments: signature.asc (0.31 KB)


dilfridge at gentoo

May 23, 2012, 9:42 AM

Post #15 of 163 (1266 views)
Permalink
Re: Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

> On Wed, 23 May 2012 14:42:37 +0200
>
> Kill it! And while we're at it, kill ChangeLogs as well!
>
> /me hides...

+1
+1
+1
+1
...

--
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing
Attachments: signature.asc (0.82 KB)


alexxy at gentoo

May 23, 2012, 9:45 AM

Post #16 of 163 (1288 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

Michał Górny писал 2012-05-23 19:33:
> On Wed, 23 May 2012 14:42:37 +0200
> Michael Weber <xmw [at] gentoo> wrote:
>
>> *if you still read this* *wow*
>>
>> Please discuss my arguments and come to the conclusions to
>> RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove
>> this bug from the blockers of "[TRACKER] portage migration to git".
>
> Kill it! And while we're at it, kill ChangeLogs as well!
>
> /me hides...

Well this can be done with *meaningfull* git commit messages =D

so +1

--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum [at] gmail
mailto:alexxy [at] gentoo
mailto:alexxy [at] omrb


robbat2 at gentoo

May 23, 2012, 9:47 AM

Post #17 of 163 (1277 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote:
> i've looked at the blockers of "[TRACKER] portage migration to git"
> [1] and want to discuss "testing git-cvsserver" [2].
>
> There are two proposed scenarios how to migrate the developers write
> access to the portage tree.
The primary reasons to continue to support CVS-style access via
git-cvsserver:
1. Lightweight partial/subtree checkouts
- Git has implemented subtree checkouts, but they still bring down a
fairly large packfile.
2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)

If we can get rid of #2, we're willing to live with #1.

> "Clean cut" turns of cvs access on a given and announced timestamp,
> rsync-generation/updates is suspended (no input -> no changes), some
> magic scripts prepare the git repo (according to [3], some hours
> duration) and we all checkout the tree (might be some funny massive load).
1. You will be given git bundles instead of being allowed to do initial
clone. That way it's just a resumable HTTP download.
2. rsync generation is NOT going away. Users will still be using it.

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2 [at] gentoo
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85


alexxy at gentoo

May 23, 2012, 9:58 AM

Post #18 of 163 (1269 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

Robin H. Johnson писал 2012-05-23 19:47:
> On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote:
>> i've looked at the blockers of "[TRACKER] portage migration to git"
>> [1] and want to discuss "testing git-cvsserver" [2].
>>
>> There are two proposed scenarios how to migrate the developers write
>> access to the portage tree.
> The primary reasons to continue to support CVS-style access via
> git-cvsserver:
> 1. Lightweight partial/subtree checkouts
> - Git has implemented subtree checkouts, but they still bring down
> a
> fairly large packfile.
> 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)

Isnt git works with shallow clone? like
# git clone --depth 1 <or any other desired value>
git+ssh://gitrepo.uri::repo

So you can clone in this manner and push changes back

Also for depth = 1 pack size will be similar to gzipped rsync snapshot
(~40M)


> If we can get rid of #2, we're willing to live with #1.
>
>> "Clean cut" turns of cvs access on a given and announced timestamp,
>> rsync-generation/updates is suspended (no input -> no changes), some
>> magic scripts prepare the git repo (according to [3], some hours
>> duration) and we all checkout the tree (might be some funny massive
>> load).
> 1. You will be given git bundles instead of being allowed to do
> initial
> clone. That way it's just a resumable HTTP download.
> 2. rsync generation is NOT going away. Users will still be using it.

--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum [at] gmail
mailto:alexxy [at] gentoo
mailto:alexxy [at] omrb


jlec at gentoo

May 23, 2012, 9:58 AM

Post #19 of 163 (1268 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On 23.05.2012 18:47, Robin H. Johnson wrote:
> On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote:
>> i've looked at the blockers of "[TRACKER] portage migration to git"
>> [1] and want to discuss "testing git-cvsserver" [2].
>>
>> There are two proposed scenarios how to migrate the developers write
>> access to the portage tree.
> The primary reasons to continue to support CVS-style access via
> git-cvsserver:
> 1. Lightweight partial/subtree checkouts
> - Git has implemented subtree checkouts, but they still bring down a
> fairly large packfile.
> 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)
>
> If we can get rid of #2, we're willing to live with #1.
>
>> "Clean cut" turns of cvs access on a given and announced timestamp,
>> rsync-generation/updates is suspended (no input -> no changes), some
>> magic scripts prepare the git repo (according to [3], some hours
>> duration) and we all checkout the tree (might be some funny massive load).
> 1. You will be given git bundles instead of being allowed to do initial
> clone. That way it's just a resumable HTTP download.
> 2. rsync generation is NOT going away. Users will still be using it.
>

Was this a vote for or against a quick proceeding towards git?
You are probably the one who can judge best if the infra side could be
made ready soonish.
Attachments: signature.asc (0.29 KB)


mattst88 at gentoo

May 23, 2012, 9:59 AM

Post #20 of 163 (1267 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On Wed, May 23, 2012 at 12:47 PM, Robin H. Johnson <robbat2 [at] gentoo> wrote:
> 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)

Please don't go to this trouble for the ability to commit to portage
on *really* slow systems.


alexxy at gentoo

May 23, 2012, 10:06 AM

Post #21 of 163 (1267 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

Matt Turner писал 2012-05-23 19:59:
> On Wed, May 23, 2012 at 12:47 PM, Robin H. Johnson
> <robbat2 [at] gentoo> wrote:
>> 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)
>
> Please don't go to this trouble for the ability to commit to portage
> on *really* slow systems.

Isnt cvs too sloow on mips? git is much more faster. Same for arm.
About big repos, well why not use shallow cloned repo. It will work
with plane history
--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum [at] gmail
mailto:alexxy [at] gentoo
mailto:alexxy [at] omrb


alexxy at gentoo

May 23, 2012, 10:09 AM

Post #22 of 163 (1271 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

Robin H. Johnson писал 2012-05-23 19:47:
> On Wed, May 23, 2012 at 02:42:37PM +0200, Michael Weber wrote:
>> i've looked at the blockers of "[TRACKER] portage migration to git"
>> [1] and want to discuss "testing git-cvsserver" [2].
>>
>> There are two proposed scenarios how to migrate the developers write
>> access to the portage tree.
> The primary reasons to continue to support CVS-style access via
> git-cvsserver:
> 1. Lightweight partial/subtree checkouts
> - Git has implemented subtree checkouts, but they still bring down
> a
> fairly large packfile.
> 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS)
>
> If we can get rid of #2, we're willing to live with #1.
>
>> "Clean cut" turns of cvs access on a given and announced timestamp,
>> rsync-generation/updates is suspended (no input -> no changes), some
>> magic scripts prepare the git repo (according to [3], some hours
>> duration) and we all checkout the tree (might be some funny massive
>> load).
> 1. You will be given git bundles instead of being allowed to do
> initial
> clone. That way it's just a resumable HTTP download.
> 2. rsync generation is NOT going away. Users will still be using it.


Another good point for repo size

https://git.wiki.kernel.org/index.php/GitFaq#How_do_I_use_git_for_large_projects.2C_where_the_repository_is_large.2C_say_approaching_1_TB.2C_but_a_checkout_is_only_a_few_hundred_MB.3F_Will_every_developer_need_1_TB_of_local_disk_space.3F
--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum [at] gmail
mailto:alexxy [at] gentoo
mailto:alexxy [at] omrb


robbat2 at gentoo

May 23, 2012, 10:19 AM

Post #23 of 163 (1266 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On Wed, May 23, 2012 at 07:58:17PM +0300, Alexey Shvetsov wrote:
> Isnt git works with shallow clone? like
> # git clone --depth 1 <or any other desired value>
> git+ssh://gitrepo.uri::repo
>
> So you can clone in this manner and push changes back
>
> Also for depth = 1 pack size will be similar to gzipped rsync snapshot
> (~40M)
The shallow clone is still a shallow clone of the entire repo, and you
get the subtree checkout as just part of that.

Shallow clones are also read-only last I checked.

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2 [at] gentoo
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85


alexxy at gentoo

May 23, 2012, 10:22 AM

Post #24 of 163 (1270 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

Robin H. Johnson писал 2012-05-23 20:19:
> On Wed, May 23, 2012 at 07:58:17PM +0300, Alexey Shvetsov wrote:
>> Isnt git works with shallow clone? like
>> # git clone --depth 1 <or any other desired value>
>> git+ssh://gitrepo.uri::repo
>>
>> So you can clone in this manner and push changes back
>>
>> Also for depth = 1 pack size will be similar to gzipped rsync
>> snapshot
>> (~40M)
> The shallow clone is still a shallow clone of the entire repo, and
> you
> get the subtree checkout as just part of that.
>
> Shallow clones are also read-only last I checked.

That isnt true =) you can commit from shallow clone if and only if
original repo doesnt have a branching and merging points before and
after shallow clone point respectively
--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Gatchina, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum [at] gmail
mailto:alexxy [at] gentoo
mailto:alexxy [at] omrb


rich0 at gentoo

May 23, 2012, 10:32 AM

Post #25 of 163 (1266 views)
Permalink
Re: Portage Git migration - clean cut or git-cvsserver [In reply to]

On Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov <alexxy [at] gentoo> wrote:
>
> That isnt true =) you can commit from shallow clone if and only if original
> repo doesnt have a branching and merging points before and after shallow
> clone point respectively
>

Is that going to be a practical condition to maintain?

And how big will the repository actually be? Are we talking a GB or
two, or something orders of magnitude larger?

Rich

First page Previous page 1 2 3 4 5 6 7 Next page Last page  View All Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.