| 1 |
On Tue, 16 Sep 2014 10:52:13 -0700 |
| 2 |
"W. Trevor King" <wking@×××××××.us> wrote: |
| 3 |
|
| 4 |
> On Tue, Sep 16, 2014 at 05:35:08PM +0000, Duncan wrote: |
| 5 |
> > W. Trevor King posted on Mon, 15 Sep 2014 13:33:46 -0700 as |
| 6 |
> > excerpted: |
| 7 |
> > > On Mon, Sep 15, 2014 at 01:29:44PM -0700, W. Trevor King wrote: |
| 8 |
> > >> I don't see any benefit to using rsync vs. a shallow clone as the |
| 9 |
> > >> transmission protocol. |
| 10 |
> > > |
| 11 |
> > > Other than the fact that before you dropped it you'd need to push |
| 12 |
> > > a ‘emerge sync’ that could handle either rsync or Git, stabilize |
| 13 |
> > > that Portage, and then wait for folks to adopt it. |
| 14 |
> > |
| 15 |
> > Portage already handles it. =:^) |
| 16 |
> |
| 17 |
> Oh, lovely :). Looks like that landed in 2.2.0 with 47e8d22d (Add |
| 18 |
> support for multiple repositories in `emerge --sync`, 2013-07-23). |
| 19 |
> There are older Portages in the tree though (back to 2.1.6.7_p1), so |
| 20 |
> you'd still want to wait until those were gone before dropping rsync. |
| 21 |
> |
| 22 |
> Also, I don't see a way to say “use Git to sync, but keep a shallow |
| 23 |
> repository”. Ideally, we'd want: |
| 24 |
> |
| 25 |
> $ git clone --depth=1 git://git.gentoo.org/gentoo-portage.git |
| 26 |
> |
| 27 |
> for the initial clone (modulo whatever URI), and: |
| 28 |
> |
| 29 |
> $ git pull --depth=1 |
| 30 |
> |
| 31 |
> for subsequent syncs. pym/_emerge/actions.py currently hardcodes ‘git |
| 32 |
> pull’ for the latter, and doesn't seem to have any code for the |
| 33 |
> former. On the other hand, it wouldn't be too terrible to force users |
| 34 |
> to shallow their history manually whenever they felt like it. |
| 35 |
> |
| 36 |
> Cheers, |
| 37 |
> Trevor |
| 38 |
> |
| 39 |
|
| 40 |
The depth option will be added to the new portage plugin-sync system in |
| 41 |
final stages of development now. |
| 42 |
|
| 43 |
There will be 2 new repos.conf options |
| 44 |
|
| 45 |
1 for new repo install |
| 46 |
eg. git clone: --depth=1 |
| 47 |
|
| 48 |
another for sync options: |
| 49 |
eg. git pull: --rebase origin master |
| 50 |
this will allow changes to a repo in a different branch be |
| 51 |
updated from the master branch. |
| 52 |
|
| 53 |
they will be repo specific options, not global. |
| 54 |
|
| 55 |
|
| 56 |
The new system will allow |
| 57 |
emerge-webrync type repos to be synced via emerge --sync instead of the |
| 58 |
emerge-webrsync command. Plus it will add an svn type and the ability |
| 59 |
for a layman type which layman already has code for. Layman is just |
| 60 |
waiting for the new sync system to land in portage's master branch |
| 61 |
before enabling it to be installed. It will also allow for third party |
| 62 |
sync modules to be created and easily installed. So a squashfs sync |
| 63 |
type could be created and installed for those repos where that a |
| 64 |
squashfs tree is offered. |
| 65 |
|
| 66 |
-- |
| 67 |
Brian Dolbec <dolsen> |
Archives