[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ripping out GLib bindings, depending on GLib
From: |
Andreas Rottmann |
Subject: |
Re: Ripping out GLib bindings, depending on GLib |
Date: |
Fri, 16 Jan 2004 23:09:10 +0100 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) |
Rob Browning <address@hidden> writes:
> Andreas Rottmann <address@hidden> writes:
>
>>> The base-0 revisions are both just the 1.3.4 source with a few minor
>>> (arch-related) modifications.
>>>
>> I hope you branched main--1.4 from main-dev--0...
>
> Yes, exactly.
>
> tla archive-setup g-wrap--main--1.4
> tla tag g-wrap--main-dev--0--base-0 g-wrap--main--1.4
>
> If that's not right, just let me know. It'd still be easy to start
> over ATM.
>
Perfectly fine; you could have omitted the --base-0 (yielding the same
effect) BTW.
>>> My current plan is to keep savannah CVS around, but try having it be
>>> read-only, and only follow g-wrap--main-dev via sync from the main
>>> arch tree -- hence the .cvsignore files in the arch repo.
>>>
>> I follow the following policy: Make .cvsignore files an exception
>> (i.e. allow writes) and keep them out of the arch repo. Having them in
>> the arch repo doesn't hurt, though.
>
> Hadn't thought about that. Guess that would have been fine too,
> though I wonder if dir rearrangements might be easier if all mods are
> done from arch (w/the .cvsignore files stored there)...
>
Yes, that's a point.
>> Hmm, is there even supposed to be a way to upload using rsync/sftp?
>> I haven't seen any docs about that.
>
> Yeah, there's some info, including this bit in the admin docs:
>
> Check the CVS page for detailed instruction. Here are three example
> commands to upload a file in your public download area:
>
> rsync --rsh=ssh distribution.tar.gz \
> address@hidden:/upload/g-wrapg-wrap
> sftp -1 address@hidden:/g-wrap
> scp distribution.tar.gz address@hidden:/upload/g-wrapg-wrap
>
Well, I still wonder if you can upload entire directory trees...
> In general, am I right in presuming that making the arch repo
> publically available, even if only read-only should help a lot,
> (i.e. making it possible to generate changesets, etc.),
>
Sure! Having just read-only archives (and a read-write one for
yourself) is (most?) common practice with Arch /methinks.
> and that if/when I'm ready to make it read-write, I can do that via
> various methods, including tla-pqm (which I'm not familar with yet)?
>
I think the best way would be, if we go "centralized", to set up a new
archive (named something like address@hidden) and then
tag the branches in there from your current archive (plus cachrev them
in the new archive for efficiency). Rythmbox is setup this way, have a
look at [1]; the public archive is branched from Walters' private one.
[1]
http://web.rhythmbox.org/arch/2004/rhythmbox/rhythmbox--main/rhythmbox--main--0.7/base-0/CONTINUATION
Andy
--
Andreas Rottmann | address@hidden | address@hidden | address@hidden
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Packages should build-depend on what they should build-depend.
- Re: Ripping out GLib bindings, depending on GLib, Andy Wingo, 2004/01/16
- Re: Ripping out GLib bindings, depending on GLib, Andreas Rottmann, 2004/01/16
- Re: Ripping out GLib bindings, depending on GLib, Rob Browning, 2004/01/16
- Re: Ripping out GLib bindings, depending on GLib, Andreas Rottmann, 2004/01/16
- Re: Ripping out GLib bindings, depending on GLib, Rob Browning, 2004/01/16
- Re: Ripping out GLib bindings, depending on GLib,
Andreas Rottmann <=
- Re: Ripping out GLib bindings, depending on GLib, Rob Browning, 2004/01/16
- Re: Ripping out GLib bindings, depending on GLib, Andreas Rottmann, 2004/01/16
- Re: Ripping out GLib bindings, depending on GLib, Rob Browning, 2004/01/16
- Re: Ripping out GLib bindings, depending on GLib, Rob Browning, 2004/01/18
- Re: Ripping out GLib bindings, depending on GLib, Andreas Rottmann, 2004/01/18
- Re: Ripping out GLib bindings, depending on GLib, Rob Browning, 2004/01/18