On 23/08/2007, at 7:12 AM, Stephen Connolly wrote:
Or a better local repository model ;-)
+1. I already started to draft a proposal for the wiki on this, but
hadn't posted it yet.
One where there are two local repositories (committed and current
build) that get layered together.
What I was actually thinking was the lock operating at the individual
artifact level, and being a read lock as well as a write lock. The
installation step itself should be very quick for the artifact and
it's associated metadata because they are already built, so this is
not a bad lock to have, and I think it's still necessary to have a
read lock because there's no way to atomically do the merge you refer
to later on.
One of the advantages of what you were describing is the ability to
not install anything unless the entire build passes - that has some
virtues as well, but I consider it a separate feature to fixing the
local repository concurrency problems.
If you have layering, then you could have a shared local repository
as a third layer to save duplication of files.
Yes, this is definitely something I'd like to see. I think that we
should be separating the cache from the place that developers install
their own things. There are a number of reasons this is a good idea:
1) it would simplify a lot of the artifact handling code
2) it lets you clean up easily - you likely keep your cache but nuke
your local builds
3) you can create separate local repository workspaces on a single
machine without needing to redownload all the rest of the cache
(useful for CI servers)
4) you could start to share a cache (though I'd still recommend a
shared remote repository instead of doing this, it's at least less
harmful than doing it now)
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
