> > Will we continue to keep the source tarballs in the gate, or will they be
> > external? I know that mercurial has had performance problems with large
> > binary blobs in the past; I don't know if they've been solved.
>
> My plan is to transition as-is which yes, means keep the source tarballs
> in the gate. I actually like that as I don't like having the build
> possibly fail in the middle because it can't download something.
If this is the only concern, we can very easily do some checksum over
the downloaded files before trying to build them. The checksum would be
stored in the workspace itself. Ideal would be if every product would
download it's sources prior to compilation, but as a first step we could
provide script which would download and verify all necessary sources. In
the future it would allow us to simply build only relevant products (for
building gtar you would not have to download and compile gtk libraries
for example).
> > Also note
> > that as of now, there's no way to eradicate history, so all the old
> > versions of things will stick around forever, even long past the time we've
> > stopped caring, and people building current workspaces don't want to
> > download stuff.
>
> My view there is, if we reach a point where the workspace becomes too
> big because of deletions that don't really delete, we could always
> create a new workspace without them and switch to that, leaving the
> old one around forever so old bits can be found and built if necessary
> (and yes, it can be, I seem to be in teamware's deleted_files a lot).
That is certainly possible. But there are three negative things
a) new repository will not be related to old one, so if someone has
some local changes to his clone, hg would not be able to merge his
changes automatically.
b) we would either loose history during the transition, or we would have
to use the 'convert' extension and handpick every 'old' source. (granted
it could be scripted to some degree)
c) if you would want to go to old build, you would have to first find
which repository it lies in. So we would need some sort of additional
index on the top of mercurial repositories.
> If there are issues doing it this way then I am quite open to not doing
> this transition now and allowing others to do it, so feel free :) I'm
> just feeling pressure on this so thought I'd give it a shot, but I'm
> not in a hurry there are bugs to fix as well.
Where is the pressure coming from ? If it's because we want to give
community the possibility to contribute, we should first create proper
tools for it first. I can hardly imagine 1G of sources just to bump up
gtar revision ...
I would be happy to help. But first it would be good IMO to define what
is our goal.
--
Vlad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/sfwnv-discuss/attachments/20080917/3d28e44e/attachment.bin>
