This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [HEADSUP] Let's start a Cygwin 1.7 release area


On Sun, Apr 13, 2008 at 11:03:14AM +0200, Corinna Vinschen wrote:
>On Apr 12 23:43, Christopher Faylor wrote:
>> On Fri, Apr 11, 2008 at 05:13:33PM +0200, Corinna Vinschen wrote:
>> >I've now created a release-2 area.  I used a somewhat intermediary
>> >approach.  The dirs are real dirs, the tar.bz2 files are symlinks
>> >to the release area, the setup.hint and md5.sum files are copies.
>> >The cygwin subdir only contains 1.7.0-1 packages.
>> >
>> >Chris, could you please set up another upset which creates the
>> >corresponding setup-2.{bz2,ini} files?
>> 
>> I have another way to do this using a union fs.  Using a union fs means
>> that we can have a cygwin-2 directory which mirrors the old cygwin
>> directory, gaining the benefits of hardlinking, but also allowing
>> removals in the new directory without affecting the old cygwin
>> directory.
>> [...]
>> The only downside to this is that the mirrors will apparently be copying
>> all of the data twice.
>
>That's what I was trying to avoid.  In the long run you will have
>two separate areas but the load of the mirroring is stretched out
>over time.  Probably I'm just still living in modem times...
>
>> all of the data twice.  So, we could remove all of the obsolete files
>> and older revisions from this new release directory to minimize the
>> extra copying.
>
>That might help a lot.  If every package dir only contains the latest
>versions you would have less than half the size.  The only problem
>would be that you have to grep the setup.hint files and remove
>potential version information.

Actually the difference is 3122332 purged vs. 4640060 unpurged.

I am not sure how much to worry about the effect on the mirrors.  It
seems like there would be an additional flurry of activity that would
eventually just die down.  I hate to make supportability decisions based
on external constraints.

That does raise the issue of the mirror checking software that runs to
make sure that a mirror is valid.  It seems like that may need to be
tweaked no matter what we do.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]