Process workflow--pulling remote repos (was: diff to tag includes .hgtags)

[solo turn]

On 6/28/05, Matt Mackall <mpm at selenic.com> wrote:
> On Tue, Jun 28, 2005 at 03:30:33PM -0400, Kevin Smith wrote:
> > Matt Mackall wrote:
> Q. What are some best practices for distributed development with
> Mercurial?
> 
> First, merge often! This makes merging easier for everyone and you
> find out about conflicts (which are often rooted in incompatible
> design decisions) earlier.
> 
> Second, don't hesitate to use multiple trees locally. Mercurial makes
> this fast and light-weight. Typical usage is to have an incoming tree,
> an outgoing tree, and a separate tree for each area being worked on.
> 
> The incoming tree is best maintained as a pristine copy of the
> upstream repository. This works as a cache so that you don't have to
> pull multiple copies over the network. No need to check files out here
> as you won't be changing them.
> 
> The outgoing tree contains all the changes you intend for merger into
> upsteam. Publish this tree with 'hg serve" or hgweb.cgi or use 'hg
> push" to push it to another publicly availabe repository.
> 
> Then, for each feature you work on, create a new tree. Commit early
> and commit often, merge with incoming regularly, and once you're
> satisfied with your feature, pull the changes into your outgoing tree.
> 

how do you pull from somebody behind a proxy? or, the other way round,
how can somebody behind a proxy get the changes to you? and how the
above szenario would change then?

could the one behind the proxy push via https to your rep (so you have
the authentication possibility via ssl)? so it would be possible to
support a quasi-centralized szenario used by kde, gnome, and others?

-solo.