1 (19:02) < Omnifarious> I'm wondering if anybody has a good reason not to push my change to crew.  :-)
   2 (19:23) < brendan> I personally just haven't thought enough about it. I have this bad feeling there's a nicer way to do this...
   3 (19:50)  * Omnifarious thinks.
   4 (19:51) < Omnifarious> So, from a UI perspective you might well be right.
   5 (19:51) < Omnifarious> I suspect you are.  I think the way the command line options here are organized isn't really the best that could be done.
   6 (19:51) < Omnifarious> But, from an internal mechanics perspective, I don't think there's a better way to do it.
   7 (19:52) < Omnifarious> I actually find the whole branch idea rather suspect.  Mostly because I think a branch is a piece of repository level information that does not belong indelibly recorded in a revision.
   8 (19:53) < Omnifarious> I think the fast-forward merge problem is actually a really great illustration of the disconnect here.
   9 (19:56) < brendan> yes, that's tricky. I am hoping the localbranch stuff will help
  10 (19:57) < brendan> something I haven't put my finger on bothers me about hg's named branches too
  11 (19:57) < Omnifarious> I think sometimes though that people have to have something to play with for awhile to know what they really want.
  12 (19:57) < brendan> I think it can work fine for 'stable' vs 'devel' though
  13 (19:59) -!- Dongsheng [n=chatzill@58.61.192.133] has joined #mercurial
  14 (20:01) < brendan> git's branches are nice in that they're throwaway, but I don't think it's very good about exporting things. I recall a lot of manually set up branch maps
  15 (20:01) < brendan> and there seems to be a bit too much rebasing
  16 (20:01) < Omnifarious> Mercurial in general has shyed away from copying repository meta-data between repositories.
  17 (20:02) < Omnifarious> I think that branches are repository meta-data, not data about revisions.  And I think it needs to be copied form repo to repo by pull, push, clone and other such utilities.
  18 (20:03) < Omnifarious> I think a branch is mostly a label you've applied to a set of heads.
  19 (20:03) < brendan> I don't think they're much different from tags, which are propagated
  20 (20:04) < Omnifarious> Yes and no.
  21 (20:04) < brendan> I don't know about this 'active branch' idea though. I think making active == 'has heads' is probably wrong.
  22 (20:04) < Omnifarious> Hmm...
  23 (20:05) < brendan> I suspect we may need to mark them manually
  24 (20:06) < Omnifarious> So, here is why I think branches are different than tags....
  25 (20:06) < Omnifarious> Tags are a fact about a particular revision.
  26 (20:07) < Omnifarious> Once that fact is recorded, it doesn't change.
  27 (20:07) < Omnifarious> A branch is something that's about a group of revisions and future revisions.
  28 (20:07) < brendan> we do have some logic for tag movement though
  29 (20:08) < Omnifarious> Yes, but it's not like the tag is ever applied to two revisions at once.
  30 (20:08) < brendan> hmm
  31 (20:09) < Omnifarious> I don't know...  do people ever have a 'latest stable release' tag that just gets updated all the time instead of labeling each stable release with a different tag?
  32 (20:10) < Omnifarious> Even then that feels fundamentally different from a branch which seems a much more distributed and amorphous idea.
  33 (20:10) < brendan> don't know. seems plausible though
  34 (20:11) < brendan> well, a branch is basically a distinct changelog, but we need a way to make them live together
  35 (20:18) < Omnifarious> I sort of think of a branch as being a little piece of meta-data about a particular repo.
  36 (20:19) < Omnifarious> It's like "Hey, when we put stuff here, it's for this."
  37 (20:21) < Omnifarious> And if you pull from a repo that isn't for that purpose, those changes should be invisible by default in your repo.
  38 (20:21) < Omnifarious> Hmmm...
  39 (20:22) < Omnifarious> So, here's a concrete idea...
  40 (20:22) < Omnifarious> There is no data about branches in any individual revision.
  41 (20:23) < Omnifarious> It exists solely in the branch cache, which can be propogated between repos.
  42 (20:23) < brendan> this recalls the old idea of having a .hgbranches file
  43 (20:24) < Omnifarious> But this branch cache is not version controlled.
  44 (20:24) < Omnifarious> A repo updates it based on a set of distinct rules when a new version is committed or a revision is pulled.
  45 (20:24) < brendan> hmm. you might get some pushback about that.
  46 (20:25) < brendan> I remember mpm being of the opinion that propagation in hg was best done through the version control mechanism
  47 (20:25) < Omnifarious> Each branch cache entry consists of a branch name and a set of revisions that are considered heads.
  48 (20:25) < brendan> the mq nested repo approach might work around that though
  49 (20:26) < Omnifarious> If a new cache entry is recieved for a particular branch it removes any cache entries for revisions that are ancestors of the new entry.
  50 (20:26) < Omnifarious> You also have a 'working branch' recorded like the dirstate.
  51 (20:27) < Omnifarious> And by default all commands only show you data about the 'working branch' if one is recorded.
  52 (20:27) < brendan> sounds like you're replacing the heads algorithm
  53 (20:27) < brendan> also sounds like it's going to look like localbranches
  54 (20:27) < brendan> !localbranches
  55 (20:27) < hgbot> brendan: Error: "localbranches" is not a valid command.
  56 (20:27) < brendan> !whatis localbranch
  57 (20:27) < hgbot> brendan: "localbranch" could be http://www.selenic.com/mercurial/wiki/index.cgi/LocalBranches
  58 (20:29) < Omnifarious> Yes, it's very much like that idea.  Except with the added feature of having them propogate between repositories.
  59 (20:29) < brendan> yes, that's a bit I wanted to add in
  60 (20:30) < Omnifarious> I think all branches are 'short-lived'.  You might have a recurring development branch that forks off, but it always comes back to the stable branch.
  61 (20:31) < codemac> I think that is a massive assumption about how others see their branches
  62 (20:31) < brendan> otoh I think short-lived branches can be very handy
  63 (20:32) < brendan> would be nice to support them. I've got some time to myself this weekend and I hope I can take another crack at the localbranch queue
  64 (20:32) < brendan> I think transient branches are the biggest thing git users miss in hg
  65 (20:33) < brendan> transient branch by cloning can be a bit annoying
  66 (20:33) < Omnifarious> codemac: Well, I think this even accomodates long-term branches.
  67 (20:33) < Omnifarious> brendan: I've been meaning to re-write the little contrib thingy that relinks files that are identical.
  68 (20:33) < codemac> Omnifarious: I haven't checked out your code yet, I was just reacting to your statement :P
  69 (20:34) < brendan> Omnifarious: ok. it was a pretty quick hack
  70 (20:34) < Omnifarious> codemac: Oh, my code is based on the current branch model in which branches are forever and can never be forgotten.
  71 (20:34) < Omnifarious> brendan: *nod*  I've been meaning to change it to determine if two files are identical by comparing head lists.  :-)
  72 (20:35) < brendan> yep, that's probably a good idea
  73 (20:35) < brendan> I think it already only compares indices though
  74 (20:35) < Omnifarious> I have to disappear in a minute or two.
  75 (20:35) < Omnifarious> Oh, well that's a good thing.
  76 (20:36) < Omnifarious> Does it do a repo write lock on both repos while it's running?
  77 (20:36) < brendan> no
  78 (20:36) < brendan> it started out as a generic relinker
  79 (20:37) < brendan> anyway, you're welcome to make it smarter :)
  80 (20:37)  * Omnifarious nods.
  81 (20:37) < Omnifarious> It would reduce the annoyance of lots of clones.  :-)
  82 (20:37) -!- You're now known as Omni|AFK
  83 (20:37) < brendan> would be cool if it could do more than pairs :)
  84 (20:37)  * Omni|AFK nods.
  85