On Friday, August 1, 2003, at 07:00  PM, Derek Brans wrote:

> I'm floundering a bit in understanding Monticello.
>  
> I want to have an "always online" server hosting a repository where my 
> code can be found.  I have the server, which has up until now hosted 
> my CVS repository.
>  
> How does one setup a Remote Monticello Repository? 

The current release only works with repositories on the file system. To 
have a repository on a remote machine, you need to mount that directory 
on your local machine somehow. I've found that WebDAV works great for 
this. I've set up Apache2 and mod_dav, then mounted the repository 
directory as a remote volume under OS X. On Windows, WebFolders seems 
to work pretty well too.

The next release will include an HTTP-client repository that can use a 
WebDAV repository directly. We've kicked around a few ideas for a more 
CVS-like network repository that provides branch management, email 
notification of commits and so on, but there aren't any concrete plans 
yet.

> The discussion around MC seems to say that we are done with 
> centralized repositories.  What is meant by this?  Isn't it handy to 
> have one repository to manage code, so it doesn't start branching in 8 
> directions?
>  
> Are we talking about a community of developers working and 
> intermittingly merging)?  How is that different than the cvs model?

Well, I don't know that central repositories are a thing of the past, 
but it's nice that we don't *have* to do it that way. We definitely do 
want to support that "community of developers working separately and 
intermittently merging" model since that's how most Squeak development 
seems to work.

CVS does a good job of allowing developers to work concurrently, but it 
doesn't handle distributed and disconnected development very well. If 
you're cut off from the net, there's not a lot you can do with CVS. 
Maintaining a local mirror of a CVS repository is possible, but 
difficult. Moving versions between CVS repositories is damn near 
impossible.

By de-emphasizing repositories, Monticello gives us a lot more 
flexibility. Pretty much any collection of versions can be considered a 
repository and Monticello will make a 
best-effort-with-available-information if you don't have the complete 
history of a package all in one place.

Frankly, I'm not sure what the development model for working with 
Monticello will be. What we've got now is just a flexible base for 
building more elaborate tools.

Does this make any sense?

Colin