<br><br><div class="gmail_quote">On Thu, Feb 24, 2011 at 8:19 PM, Jason Harris <span dir="ltr"><<a href="mailto:jason@jasonfharris.com">jason@jasonfharris.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5"><br>
On Feb 24, 2011, at 7:39 PM, timeless wrote:<br>
<br>
> On Thu, Feb 24, 2011 at 8:19 PM, Jason Harris <<a href="mailto:jason@jasonfharris.com">jason@jasonfharris.com</a>> wrote:<br>
>> Shouldn't the history editing tools then be better here? Which is the real issue. The immutability of history is not really what you care about here it seems like... :)<br>
><br>
> history editing doesn't help if you only find out history isn't ok<br>
> after you push to another host because some other client pulled from<br>
> that host and complained to someone. it's already partially out in the<br>
> wild.<br>
><br>
> picture:<br>
><br>
> <manager> - <anal-bot><br>
> | |<br>
> <dev> - <internal-dvcs> - <publisher> - <public-dvcs><br>
> |<br>
> <other-dev><br>
><br>
> steps:<br>
> 1. dev pushes something to internal-dvcs.<br>
> 2. other-dev pulls from internal-dvcs<br>
> 3. anal-bot pulls from internal-dvcs<br>
> 4. anal-bot sends a report to manager<br>
> 5. manager sends a report to dev<br>
><br>
> 6. dev cries<br>
><br>
> 6-1. dev needs to do something to satisfy manager | anal-bot, but<br>
> <internal-dvcs> is append only.<br>
><br>
> 7. publisher doesn't publish to <public-dvcs> until much later (or<br>
> never if ordered not to by manager because of anal-bot report).<br>
><br>
> 6-2. If dev can fix commit message to satisfy <anal-bot>, then life is<br>
> better for dev.<br>
><br>
> 7-1. if <publisher> can use |hg convert| to fold those messages later<br>
> before publishing to <public-dvcs>, then publication is more likely to<br>
> happen. the alternative is roughly an export of a single delivered<br>
> version (because of <anal-bot>/<manager>).<br>
><br>
> Note that as there's a general mapping available to <publisher> for<br>
> <internal-dvcs> and <public-dvcs>, the fact that the changeset ids<br>
> don't match doesn't really bother anyone too much. If this didn't<br>
> happen, they'd still not match, but the tree topology wouldn't match<br>
> either (single commit dumps for an entire release).<br>
<br>
</div></div>Well with that work flow, yep you are farily out of luck. Even so what happens if the problem is not just a commit message but say EOL wasn't correct. Then even with this extension you are still hosed. Or the anal-bot is some continuous integration server and has rejected the changes due to failing tests or something.<br>
<br>
In any case I would suggest changes to the workflow but you like would already change it if you could...<br>
<br>
Cheers,<br>
Jas<br>
<div><div></div><div class="h5"><br>
_______________________________________________<br>
Mercurial-devel mailing list<br>
<a href="mailto:Mercurial-devel@selenic.com">Mercurial-devel@selenic.com</a><br>
<a href="http://selenic.com/mailman/listinfo/mercurial-devel" target="_blank">http://selenic.com/mailman/listinfo/mercurial-devel</a><br>
</div></div></blockquote></div><br>I think that fixing an invalid commit message is in fact harder than fixing say a file with wrong EOL.To fix a file that is tracked by mercurial you can fix it and commit, creating a new changeset. But you cannot fix a commit message by making a new changeset!<br>
<br>Angel<br><br>