Hello again,<div><br></div><div>Thanks for the ideas Titus. For my next task, I am thinking I should work on building more build scripts. I had trouble with my last one so I want to work on something similar so that I am more confident but in a different repo maybe. So I will work on svn stuff.I will update you soon.</div>
<div><br></div><div>Thanks again!</div><div><br></div><div>Khushboo</div><div><br><div class="gmail_quote">On Wed, Feb 24, 2010 at 11:59 PM, Augie Fackler <span dir="ltr"><<a href="mailto:lists@durin42.com">lists@durin42.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Wed, Feb 24, 2010 at 11:57 PM, C. Titus Brown <<a href="mailto:ctb@msu.edu">ctb@msu.edu</a>> wrote:<br>
> On Wed, Feb 24, 2010 at 11:54:41PM -0600, Augie Fackler wrote:<br>
>> On Feb 24, 2010, at 11:55 AM, C. Titus Brown wrote:<br>
>>><br>
>>> Second, one of you could implement branch support for HgClone. Right<br>
>>> now GitClone supports branches other than 'master', the default, while<br>
>>> HgClone does not support branches other than 'default'. I know beans<br>
>>> about Mercurial, though, so this would be a reasonably independent<br>
>>> research project ;). To get started, here are some things you could<br>
>>> do --<br>
>><br>
>> In practice, using non-default branches in OSS is pretty rare. We're<br>
>> using it for Mercurial itself, but only for tracking "stable" versus<br>
>> "default," which is pretty minimal all told. When bookmarks become<br>
>> pushable (no real firm timeline on that), they'll probably see much more<br>
>> use.<br>
><br>
> Hmm, didn't know that -- thanks! I want to support them so that<br>
> we can test experimental branches and default branches from the same<br>
> repository. It seems like a git-tish thing, maybe.<br>
<br>
</div>That's certainly more common in the git community, probably because hg<br>
tends towards using patch queues for some reason. I'm *expecting*<br>
pushable bookmarks to change that somewhat, but we'll see how that<br>
works out when they're really around - it's very hard to predict what<br>
users will actually adopt.<br>
<div><div></div><div class="h5"><br>
><br>
>>> I can hook you up with one of the Mercurial maintainers quite easily<br>
>>> if you<br>
>>> need that level of expertise, BTW. (You shouldn't but it's always<br>
>>> nice to<br>
>>> have it on tap!)<br>
>><br>
>> I'm around, I'm not a member of crew, but I've done quite a bit with<br>
>> Mercurial internals and can easily get ahold of them if there's a<br>
>> question I can't answer. Also, I'm in UTC-6, so I'm probably a bit<br>
>> closer TZ-wise to you folks. Feel free to ask questions in #mercurial -<br>
>> it's well staffed by experts from morning in Europe until fairly late in<br>
>> the day in the US. mercurial{,-devel>@<a href="http://selenic.com" target="_blank">selenic.com</a> are both good resources<br>
>> as well, with more eyes but higher latency.<br>
><br>
> Thanks!<br>
><br>
> --titus<br>
> --<br>
> C. Titus Brown, <a href="mailto:ctb@msu.edu">ctb@msu.edu</a><br>
><br>
<br>
_______________________________________________<br>
pony-build mailing list<br>
<a href="mailto:pony-build@lists.idyll.org">pony-build@lists.idyll.org</a><br>
<a href="http://lists.idyll.org/listinfo/pony-build" target="_blank">http://lists.idyll.org/listinfo/pony-build</a><br>
</div></div></blockquote></div><br></div>