On Jun 4, 2013, at 4:23 AM, Mike Williams <[email protected]> wrote:
> 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. > Right. What would be really great would if we could support both workflows completely, and even better if we could transparently mix the two. I bet we could with some clever use of hooks and the GitHub/bit bucket Apis. I'll give it a shot with GitHub and post back with my findings. Anyone willing to try the same with emailing patches/integrating the bit bicker issue tracker and mercurial? >>> 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. > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
