On Wed, 29 Jul 2009, Bjoern Michaelsen wrote:
Guido Ostkamp <ooo <at> ostkamp.fastmail.fm> writes:
Mercurial lacks support for cheap inline feature branching and you
always have to clone the whole repo (note that I do not mean 'named
branches' in a single repo which Mercurial supports because those
cannot be removed from history anymore and they also would be pushed if
you push from the repo).
Thats very misleading:
Not at all.
- You do not have to use named branches, simply commiting on an older
revision creates an anonymous branch.
Indeed, it does. But who wants an *anonymous* branch where after a while
you don't remember what it was used for?
- You can selectively push/pull branches (thereby "removing them from
history" as much as is possible in _any_ DSCM)
If you go
hg up -C <earlierrevision>
<change>
hg commit
hg up -C <original-top-changeset>
hg push
then Mercurial denies pushing because it would create remote heads. It is
clear that it tries to publish your anonymous branch which is unwanted
behaviour.
If you merge first, push will of course become possible, but it will also
push all the revisions from your branch, which is again unwanted.
You could theoretically 'hg clone -r <changeset>' and get only that single
branch with all unmerged other branches stripped off. And you could 'hg
pull -r <changeset> some other branches into it.
So you would need 1 clone and n-1 pull's to remove one unmerged branch.
The same that you can achieve in Git with just one call
git branch -D sillybranch
in very little time.I think it's pretty clear that Git has much better
support here.
- If you need to "rewrite history" (which is a bad idea in almost all
cases anyway) you can again do this easily with the mq extension
MQ is generally inconvenient as it operates on a stack of patches and
nothing that compares to Git's branches.
Also 'rewriting history' does not get the point. If one creates a branch
for some crazy idea, and then abort it, that is simply unneeded info and
can be removed.
Also private intermediate checkins, possibly with unfinished code changes,
are in most cases useless in a repo after a merge to the mainline.
What is needed here is to put all changes within that branch into one
changeset and apply this on top of the mainline, push the mainline change
to the master repo and finally get rid off the local branch.
That has nothing to do with 'rewriting history'. Once stuff has been
remotely pushed, then of course it should be immutable.
This costs tons of additional disk space and CPU time because you have to
rebuild everything from the ground up (object files, executables,
libraries etc.) as a feature branch (you call it CWS) always means a
separate new directory tree in Mercurial.
Not needed. In fact I just did a build of a master and a cws reusing
most of the master build just today. Works like a charm.
I would be interested to know how you did that with just one repo and no
clones and without running into the anonymous branch issues listed above.
Would it be possible to give a short example?
Even the repo history must be duplicated in Mercurial if the clone is
not to be placed on the same physical filesystem because the hardlinks
don't work in this case (which requires n times the storage).
If you really want to, you can keep all you cws in one repo (its just
easier to keep them separate). So this is again missing the point.
I don't think so because of the 'push' issue mentioned above and because
it wastes a lot of valuable disk space to have n-repos.
Furthermore you would possibly need multiple repository clones to keep
track of several remote branches in Mercurial.
Wrong again.
And again I disagree.
setup cheap branches which can be completely removed from history (when
everything is integrated upstream)
... as you can with mercurial (by selective pulling/pushing)
and you can have one base-repo
somewhere in your filesystem and multiple clones elsewhere which just
reference the base repo without copying it.
Irrelevant given the size of a mercurial repo to the size of working
copy (including solver etc.)
I don't know how Sun handles this internally , but in the large company I
work for, disk space is a serious issue, we are all on a restrictive quota
here. Even a few Gigabytes on a Solaris server cause a lot of additional
costs regarding really expensive server disks, necessary networked daily
backups in a data center etc. Some 50 Gigs can thus easily cause costs of
more than 1000 Euro per month.
Regards
Guido Ostkamp
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
