Differences between revisions 3 and 8 (spanning 5 versions)
Revision 3 as of 2006-01-26 16:12:36
Size: 938
Editor: EricHopper
Comment:
Revision 8 as of 2010-11-07 17:09:55
Size: 2213
Editor: PaulBoddie
Comment: Style edits.
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
== CVS-like working practice == = CVS-like Working Practice =
Line 3: Line 3:
In a CVS-like world, you will typically have one central repository; let's call it the "main line". This correspond's to CVS's notion of the "trunk". Mercurial allows multiple [[WorkingPractices|working practices]]. In a CVS-like world, you will typically have one central repository; let's call it the "main line". This corresponds to CVS's notion of the "trunk".
Line 7: Line 7:
Developers have direct {{{ssh}}} access (see ["SharedSSH"]) to the central repositories on a server, and push their changes directly from their local clones into the appropriate repositories. == Workflow ==

Developers have direct SSH access (see [[SharedSSH]]) to the central repositories on a server, and push their changes directly from their local clones into the appropriate repositories. Thus, the usual CVS practice would be as follows:

{{{
# Check for work done...
cvs update
# Do work, consider changes...
cvs diff
# Commit changes...
cvs commit
}}}

This doesn't always work out, and so the following workflow is typically required if `cvs commit` complains:

{{{
# Rectify conflicts, then...
cvs update
# Edit conflicts, then commit...
cvs commit
}}}

The corresponding practice would be as follows with Mercurial:

{{{
# Check for work done...
hg pull
hg update
# Do work, consider changes...
hg diff
# Commit changes...
hg commit
# Push changes...
hg push
}}}

Note that before pushing changes, the developer is free to commit as many [[ChangeSet|changesets]] as they like. If `hg push` complains about multiple heads, the following workflow becomes necessary:

{{{
# Get the remote changes and merge them...
hg pull
hg merge
# Edit any conflicts, then commit...
hg commit
# Push merged changes...
hg push
}}}

Again, the developer can defer pushing changes until later. The principal advantage of Mercurial here is that the developer need not be confronted with merging others' changes on every commit.

== Branches and merging ==

CVS-like Working Practice

Mercurial allows multiple working practices. In a CVS-like world, you will typically have one central repository; let's call it the "main line". This corresponds to CVS's notion of the "trunk".

Repositories tend to be long-lived, and the "authoritative branches" are clones of the central repository.

Workflow

Developers have direct SSH access (see SharedSSH) to the central repositories on a server, and push their changes directly from their local clones into the appropriate repositories. Thus, the usual CVS practice would be as follows:

# Check for work done...
cvs update
# Do work, consider changes...
cvs diff
# Commit changes...
cvs commit

This doesn't always work out, and so the following workflow is typically required if cvs commit complains:

# Rectify conflicts, then...
cvs update
# Edit conflicts, then commit...
cvs commit

The corresponding practice would be as follows with Mercurial:

# Check for work done...
hg pull
hg update
# Do work, consider changes...
hg diff
# Commit changes...
hg commit
# Push changes...
hg push

Note that before pushing changes, the developer is free to commit as many changesets as they like. If hg push complains about multiple heads, the following workflow becomes necessary:

# Get the remote changes and merge them...
hg pull
hg merge
# Edit any conflicts, then commit...
hg commit
# Push merged changes...
hg push

Again, the developer can defer pushing changes until later. The principal advantage of Mercurial here is that the developer need not be confronted with merging others' changes on every commit.

Branches and merging

Someone may be responsible for "back-porting" changes from a branch to the main line. They do this by pulling changes from the branch and the main line into a local repository, merging appropriately, then pushing back to the main line.

When the main line reaches a release point, someone creates a clone on the server at the appropriate revision, and people who need to work on that branch clone it, then start pushing their changes back.

CvsLikePractice (last edited 2012-06-20 16:49:32 by PaulBoddie)