mercurial - Bookmark-based hg workflow for open-source project -


in scons project, use mercurial bitbucket. we'd have several ongoing features under development different people (perhaps multiple people working on single feature, or single person working on multiple features). we've tried named branches, don't work feature development in mercurial. we'd git branch system, branches lighter weight , not permanent, still shared. other separate repos per feature, don't think we're ready (too radical), community seems bookmarks way go here; development on default branch, bookmarks each head (feature).

first question: reasonable workflow? other projects working way?

second question: having tried little, 1 thing that's confusing when hg update default it's semi-random head get; depends on 1 updated last. have hg update featurex or hg update featurey or else (a) land on random head, , (b) no bookmarks "activated" end not moving bookmark forward. seems recipe failure. assume i'm missing something. who's using workflow this: how past this?

named branches ... don't work feature development in mercurial

rlly?! use nb time, long time , can't find problems. i'm doing wrong?

forget (if happened) 1 time --new-branch on push, reject , repeat correct command minimal cost named branches usefulnesses

the community seems bookmarks way go here

  1. community must have no voice in such cases
  2. community set of idiots, if each individually is genius
  3. it must personal responsibility of project lead

is reasonable workflow?

at least steve losh in "a guide branching in mercurial" note it

are other projects working way?

why not? bookmark-style has advantages in eyes (which disadvantages @ same time in another)

when hg update default it's semi-random head get

just totally forget hg up branch-name or parameter-less , always update needed bookmark-name. if team consists of young girls short memory, can build crutches in form of 1 or 2 aliases.

in not hopeless case can

bup = update active-bookmark-name 

there active-bookmark-name placeholder assigned user bookmark (and it's user's area of responsibility edit .hgrc , replace bookmark on changing task) , user have hg up in order update bookmark , hg any in order use free-form update

for blondes , code-monkeys can prepare set of 2 aliases, 1 of overload default hg up: strictly not recommended

it possible create aliases same names existing commands, override original definitions. bad idea!

but possible, like, f.e.

update = update active-bookmark-name pup = update $1 

i.e hg up|hg update without parameters user can update bookmark, (rare) updating other changeset new command in form hg pup cset-id must used

theoretically (not tested), each coder can own unique alias, can maintained , deployed workplace in centralized manner projrc extension, using user-specific include directives fetching needed keys central's repository .hg/projrc


Comments

Popular posts from this blog

javascript - Jquery show_hide, what to add in order to make the page scroll to the bottom of the hidden field once button is clicked -

javascript - Highcharts multi-color line -

javascript - Enter key does not work in search box -