Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed2a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.001 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'subject:: [': 0.04; 'broken': 0.04; 'skip:[ 20': 0.04; 'repository': 0.05; 'subject:Question': 0.07; 'branching': 0.09; 'git': 0.09; 'integral': 0.09; 'mercurial': 0.09; 'cc:addr:python-list': 0.11; '(either': 0.16; 'ah,': 0.16; 'broken.': 0.16; 'clone': 0.16; 'combined.': 0.16; 'files:': 0.16; 'filesystem': 0.16; 'kern': 0.16; 'subject:branches': 0.16; 'files.': 0.16; 'prevent': 0.16; 'wrote:': 0.18; 'wed,': 0.18; 'commit': 0.19; 'normally': 0.19; 'subject:] ': 0.20; '(the': 0.22; 'email addr:gmail.com>': 0.22; 'preferred': 0.22; 'cc:addr:python.org': 0.22; 'merge': 0.24; '(or': 0.24; 'cc:2**0': 0.24; 'developers': 0.25; '>': 0.26; 'extension': 0.26; 'updating': 0.26; 'header:In-Reply-To:1': 0.27; 'chris': 0.29; 'feature': 0.29; 'am,': 0.29; 'tim': 0.29; 'robert': 0.30; 'message-id:@mail.gmail.com': 0.30; 'lines': 0.31; '(although': 0.31; 'anonymous': 0.31; 'branches': 0.31; 'sep': 0.31; 'probably': 0.32; 'running': 0.33; '(e.g.': 0.33; '(i.e.': 0.33; 'candidate': 0.34; 'something': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'disk': 0.36; 'example,': 0.37; 'branch': 0.38; 'e.g.': 0.38; 'skip:[ 10': 0.38; 'files': 0.38; 'rather': 0.38; 'does': 0.39; 'eventually': 0.60; 'most': 0.60; 'new': 0.61; 'name': 0.63; 'kind': 0.63; 'more': 0.64; 'total': 0.65; 'different': 0.65; 'by:': 0.65; 'to:addr:gmail.com': 0.65; 'due': 0.66; 'between': 0.67; 'natural': 0.68; 'default': 0.69; 'difference.': 0.84; 'received:mail-ob0-x22d.google.com': 0.84; '359': 0.91 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5anU79I0lxhmQvdbJt0fZO3EnpMR/+wIO58Cw+QmuV0=; b=EekR/sw3dPj85sGaVKtRhYiWcCsnTaYXnSqpYYs0MwKUfo0Hdf+tHix73+JvD9vXXR rbsMKPcn14CZdIFZHdRg594BjL4MN2WGdsBTIeG3SJKPT1d6y9j8TB0xwjgTUglr2Ern cvwkncacB2Y3+Dhgt9e4KxEIkPcA4Ns6qrIa/q1n7N1uP/6Gu9ZxlVZi3wTQXiYykMRk J/63vOa5oLwAbCuo37+a8oZarz6UuponuThGQJpwLM79zLT1lVQOuFzSACF/QyKNY7o8 5O73lLXmkWG86LTZmYwcFjWIyOtYuhT/m0rRe7eRW9Lp/phqHyQC3QRqqdC4dOTcg7oi zGpA== MIME-Version: 1.0 X-Received: by 10.60.45.211 with SMTP id p19mr28896355oem.1.1410918468524; Tue, 16 Sep 2014 18:47:48 -0700 (PDT) In-Reply-To: References: <878ulk7z7y.fsf@elektro.pacujo.net> <541829b4$0$29995$c3e8da3$5496439d@news.astraweb.com> Date: Wed, 17 Sep 2014 11:47:48 +1000 Subject: Re: [OT] Question about Git branches From: Tim Delaney To: Chris Angelico Content-Type: multipart/alternative; boundary=001a11c212881f9fd40503390ed6 Cc: "python-list@python.org" X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 121 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1410918471 news.xs4all.nl 2869 [2001:888:2000:d::a6]:41679 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:77950 --001a11c212881f9fd40503390ed6 Content-Type: text/plain; charset=UTF-8 On 17 September 2014 02:25, Chris Angelico wrote: > On Wed, Sep 17, 2014 at 2:08 AM, Robert Kern > wrote: > > Yes, but this is due to different design decisions of git and Mercurial. > git > > prioritized the multiple branches in a single clone use case; Mercurial > > prioritized re-cloning. It's natural to do this kind of branching in git, > > and more natural to re-clone in Mercurial. > I disagree that it's more natural to re-clone in Mercurial. It's just that the preferred workflow of the Mercurial developers is to use clones, anonymous branches and bookmarks (almost the same as git branches) rather than named branches - and so that is the workflow that is most associated with using Mercurial. Mercurial fully supports multiple lines of development by: 1. cloning; 2. anonymous branching (i.e. multiple heads on the same branch) - normally combined with bookmarks; 3. named branching (the branch name is an integral part of the commit); 4. all of the above combined. Eventually if you want to merge between lines of development then you end up with multiple branches (either anonymous or named) in the one repo. > Ah, I wasn't aware of that philosophical difference. Does hg use > hardlinks or something to minimize disk usage when you clone, or does > it actually copy everything? (Or worse, does it make the new directory > actually depend on the old one?) > If you clone a repo to the same filesystem (e.g. the same disk partition) then Mercurial will use hardlinks for the repository files (i.e. things in .hg). This means that clones are quick (although if you don't prevent updating the working directory while cloning that can take some time ...). Hardlinks may be broken any time changesets are added to the repo e.g. via a commit or pull. Only the hardlinks involved in the commit (and the manifest) will be broken. Mercurial provides a standard extension (relink) to re-establish hardlinks between identical storage files. For example, running hg relink in my current feature branch repo: [feature_branch_repo:65179] [feature_branch]> hg relink default relinking d:\home\repos\feature_branch_repo\.hg/store to d:\home\repos\default_repo\.hg/store tip has 22680 files, estimated total number of files: 34020 collected 229184 candidate storage files pruned down to 49838 probably relinkable files relinked 359 files (221 MB reclaimed) Tim Delaney --001a11c212881f9fd40503390ed6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 7 September 2014 02:25, Chris Angelico <rosuav@gmail.com> wro= te:
On Wed, Sep 17, 2014 at 2:08 AM, R= obert Kern <robert.kern@gmail.c= om> wrote:
> Yes, but this is due to different design decisions of git and Mercuria= l. git
> prioritized the multiple branches in a single clone use case; Mercuria= l
> prioritized re-cloning. It's natural to do this kind of branching = in git,
> and more natural to re-clone in Mercurial.

I disagree that it's more natural to re-clone in Mercur= ial. It's just that the preferred workflow of the Mercurial developers = is to use clones, anonymous branches and bookmarks (almost the same as git = branches) rather than named branches - and so that is the workflow that is = most associated with using Mercurial.

Mercurial fu= lly supports multiple lines of development by:

1. = cloning;

2. anonymous branching (i.e. multiple hea= ds on the same branch) - normally combined with bookmarks;

3. named branching (the branch name is an integral part of the com= mit);

4. all of the above combined.

=
Eventually if you want to merge between lines of development the= n you end up with multiple branches (either anonymous or named) in the one = repo.
=C2=A0
Ah, I wasn't aware of that philosophical difference. Does hg use=
hardlinks or something to minimize disk usage when you clone, or does
it actually copy everything? (Or worse, does it make the new directory
actually depend on the old one?)

If you= clone a repo to the same filesystem (e.g. the same disk partition) then Me= rcurial will use hardlinks for the repository files (i.e. things in .hg). T= his means that clones are quick (although if you don't prevent updating= the working directory while cloning that can take some time ...).

Hardlinks may be broken any time changesets are added to t= he repo e.g. via a commit or pull. Only the hardlinks involved in the commi= t (and the manifest) will be broken.

Mercurial pro= vides a standard extension (relink) to re-establish hardlinks between ident= ical storage files. For example, running hg relink in my current feature br= anch repo:

[feature_branch_repo:65179] [featu= re_branch]> hg relink default
relinking d:\home\repos\feature_= branch_repo\.hg/store to d:\home\repos\default_repo\.hg/store
tip= has 22680 files, estimated total number of files: 34020
collecte= d 229184 candidate storage files
pruned down to 49838 probably re= linkable files
relinked 359 files (221 MB reclaimed)
<= div>
Tim Delaney=C2=A0
--001a11c212881f9fd40503390ed6--