preliminary guide to Mercurial via workflows

[David I.]

> Since I'ms till stuying, I don't know what company developers have
available in general: Do you know what the > major different setups are?


> We could offer a set of workflows coined for corporate developers,
including process requirements and 
> existing infrastructure. 

I only know what my company does, so I don't have a good feel for what
companies in general have available. I think most companies use the
centralized model because you need to have a central repository of
archived, independently buildable code. That is easy to accommodate with
Mercurial if you designate one repository on a central server to be your
"official" repository for the final product. The central repository may
even be on a shared drive or filesytem where there is no need to do SSH
connections through a central server. 

I think if you have a centralized workflow example where all changes are
eventually pushed to the central repository, that is good enough for a
corporate developer to understand. One level is to show how the central
repository is on a shared filesystem, another layer is to show it on a
remote server accessed over SSH.

David 


-----Original Message-----
From: arne_bab at web.de [mailto:arne_bab at web.de] On Behalf Of Arne
Babenhauserheide arne_bab-at-web.de |Mercurial|
Sent: Tuesday, May 05, 2009 1:55 AM
To: Ishee, David M
Cc: David I.
Subject: Re: preliminary guide to Mercurial via workflows

Am Montag 04 Mai 2009 20:36:00 schrieb David I.:
> I don't think we can assume in general that a central server with SSH 
> access is available. In my company, we have a mix of Windows and UNIX 
> machines so it is easy for us. If another company is Windows-only, 
> setting up SSH access will be a project in itself...

Since I'ms till stuying, I don't know what company developers have
available in general: Do you know what the major different setups are? 

We could offer a set of workflows coined for corporate developers,
including process requirements and existing infrastructure. 

> > I think the whole guide should also be rewritten fro TortoiseHG, so

> I agree. I want to transition to using HG in our group, and I really 
> wanted to do some workflow cheatsheets for command-line, TortoiseHG, 
> and Eclipse with Mercurial plugin. Since you are doing this stuff on 
> basic workflows, maybe I can help contribute the TortoiseHG and 
> Eclipse screenshots. To be complete, we should probably have Netbeans 
> screenshots too. Doing the documentation helps me to learn Mercurial. 
> In addition, I will probably use Eclipse Mercurial for day-to-day 
> operations, but our scripted build proceedures will only work with the

> command line interface, so I need to know how to use both interfaces.
>
> It might be helpful to scan the Bazaar workflow documentation and see 
> if there are any common ideas to borrow:
http://bazaar-vcs.org/Workflows.

It looks good, though a bit too rough in the beginning for my taste. As
soon as they get to centralized, it looks better (more detailed ->
showing the actual commands). 

And I just saw a point there which I missed: "Package release"

Every workflow should have a section about how to release - or we should
have a seperate main section only about doing releases. 

Mercurial offers many advantages there, after all - including shipping
releases via a simple stable repository :)

> Is your master copy published in a wiki or a repository somewhere?

Jupp: 
-> website: http://bitbucket.org/segv/hg-website/
    I write my drafts under "text/"
-> notes: http://bitbucket.org/segv/hg-website/wiki/

Best wishes,
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
              http://infinite-hands.draketo.de