On 03/06/2013 18:42, Marc Weber wrote:
> Excerpts from Mike Williams's message of Mon Jun 03 18:11:34 +0200 2013:
>> o remotes and tracking anonymous branches
>> The equivalent to remotes would be to add new path aliases to the repo's
>> .hgrc file under [paths]. See `hg help paths` for more details on that.
>
> Example:
>
> me: having branches A,B,C
> him: having branches A,B,C
>
> using path aliases, what exactly happens if pull from "him"?
>
> If I use git I get new branches:
>
> git remote add him git:///
> git fetch him
>
> him/A
> him/B
> him/C
>
> its not required to create bookmarks. How would the mercurial workflow
> look like for this example ?
A quick 10 mins creating some example repos with divergent bookmarked
branches shows the following:
<example repo creation, bookmarking, committing and path setting elided>
F:\hg\bookmarks\marc>hg pull him
pulling from F:\hg\bookmarks\him
searching for changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 3 changes to 3 files (+3 heads)
divergent bookmark A stored as A@him
divergent bookmark B stored as B@him
divergent bookmark C stored as C@him
(run 'hg heads .' to see heads, 'hg merge' to merge)
F:\hg\bookmarks\marc>hg bookmarks
A 1:24f97714d350
A@him 4:2f35d54872a3
B 2:60706d6db7a2
B@him 5:bf894f2c55f3
* C 3:826395aa207d
C@him 6:002cd688aa9d
> Is it still that hard to "remove temporary branches" again requiring
> login etc - talking about bitbucket - does somebody know?
That is a git thing - git is happy to have history rewritten. The
mercurial approach is to not support this out of the box, but it can be
done. To help with managing history modification mercurial supports
phases which tracks changeset visibility. (There is ongoing development
to further simplify history rewriting but it is not available by default
yet - for those interested see
http://mercurial.selenic.com/wiki/ChangesetEvolution)
git is very much into feature branches and rebasing or deleting to keep
the history "nice". Mercurial is more into preserving development
history with merges of feature branches back into the main line.
Bookmarks can be deleted so the namespace is kept clean (this is why you
don't use named branches for bug fixes/feature development in mercurial
- branch names are forever).
>> The simplest approach to track new heads introduced by remotes is to add
>> a bookmark to the new tip head after the pull.
>
> So its me having to to bookmark him/A him/B him/C ?
> and if he is happening to have 30 branchees, I have to bookmark 30
> branches?
With recent versions of mercurial bookmarks are included in repo updates
using pull and push. If he is not using bookmarks then yes you would
have to bookmark them yourself if you want to track them using bookmarks
rather than trying to work out which head to use.
>> o patches by email
>> The advantage of patches being provided by email is that list members
>> can review them before loading them into their local repo first.
> I don't want to change this. I want developpers to tell the list about
> their changes - so that they get reviewed.
>
> The difference is that a mail to the mailinglist would eventualy no
> longer contain a patch file, but an url to a git pull requset
>
> Eg you can get the patch by appending ".patch" to a pull request url:
>
https://github.com/MarcWeber/vim-addon-manager/pull/120.patch
>
> Now drop the '.patch' and you'll get to the web interface. It'll tell
> you that that pull request has been closed, my last comment was "pushed
> upstream".
>
> If you comment on such a pull request you'll get notified if additional
> comments happen. This way involved people will always know what's going
> on. We still want to send important comments to the mailinglist.
Makes no difference whether using mercurial or git, it's just
bike-shedding on the process. Pros and cons for both github and
bitbucket (and kiln, and rhodecode, ...)
However you are now asking developers to do multiple steps to review a
patch. A patch in an email means it is front and centre. It can still
include a URL to whatever since that can make subsequent integration and
tracking in the local clone straightforward if you decide you want to
actually try the patch.
>> Patches can be easily imported into a repo. If the patch is not an
>> output from `hg diff` (which identifies the parent changeset) then you
>> can use the patch queue extension to quickly try it out and remove it
>> again without littering your repo with incomplete work.
> Using that patch queue extension, how can I get updates from that
> "incomplete work"? Using git remotes I'd do
>
> git fetch him
At a stab (not tested):
hg incoming --patch | hg qimport
Patch queues have pros and cons at the moment. If you are more
confident then just normally pulling and using strip later to remove
again would work. There are many ways to solving this problem, you just
have to know the tool.
>> There is nothing stopping a group of developers working on area by
>> themselves with their own repos, and then when they have got what they
>> believe is a good improvement submitting one or more patches. If would
>> be up to them to handle and collapsing or rebasing as required to get it
>> accepted by Bram. This is an early step towards possibly having a
>> trusted lieutenants workflow ;-)
> Yes, but to find out whether somebody else is working on a similar
> feature, github, bitbucket might make it easier to do an initial
> research.
>
> But you're right, I'd like to see a wiki page listing all "work being
> done" so people can look it up easily. However in practise this doesn't
> work, but pull requests like implementations do more often :/
Yep the main problem is a social organisation one, not a tool one.
Mercurial and git are both very flexible on workflows, once you have
worked out how you want to organise yourself.
>> (I'm not talking about changing the
>> official repository. I'm only talking about preparing patches)
> Me too. Well - finally it'll be Bram reviewing and merging patches.
> No doubt. Everything else would be a fork of Vim.
>
> Marc Weber
>
Mike
--
I can do what you do, you just do it better.