Coordinating work on largefiles

Na'Tosha Bard natosha at unity3d.com
Wed Oct 12 08:31:52 CDT 2011


2011/10/12 Greg Ward <greg at gerg.ca>

> Hi Na'Tosha -- it looks like the two of us are busy hacking away on
> largefiles at the same time. Great! Let's try to avoid stepping on
> each other's toes. My overriding goal is to make switching from bfiles
> to largefiles easy. Right now I'm just editing docstrings and
> comments, and I have a patch brewing to do cosmetic/whitespace/style
> fixups to make largefiles look more like the rest of Mercurial. Then
> I'm going to see what is required to switch a repo from bfiles to
> largefiles.
>

That's absolutely fine with me.  I've never used bfiles (other than some
initial testing a year or so ago), and although I think it should be easy to
convert from bfiles to largefiles, it's not in my team's interest for me to
work on that right now.  So go for it.  I'm also not doing much in the way
of refactoring at the moment (other than removing the pre-1.9 code because
it simply helped a lot with clutter and readability).


> I'll stay away from the tests until you give the go-ahead. Let me know
> if you want a hand with writing/converting tests; I know from
> experience that converting from my ill-fated "hgtest" framework to
> unified form is tedious, soul-destroying work. The least I can do is
> pitch in. Is there anything else you have your eye on that might cause
> conflicts if I work on it too?
>

My two priorities are:

1) Get the test suite converted from the old format to the new format.  I
dealt with and fixed a lot of corner-case (and not-so-corner-case) bugs with
kbfiles when my team started using it early this year and when 2.0 comes
out, I don't want there to be any regressions.  Anyone working on Mercurial
needs to be able to rely on the largefiles test suite to tell them when they
need to update something because of an API change, etc.
2) Speed up the performance where possible.  For example:  I actually did
some digging and realized that "hg status" is quite fast with vanilla
"largefiles" on our repository and most of the slowness was in the current
duct-tape code being used to make regular largefiles work with Kiln (which
is not part of the regular largefiles repo).  I did, however, discover that
the slow time for "hg commit" on repos with several really large largefiles
is present in the standard largefiles extension, so I have a patch ready for
that.

So unless you're working specifically on performance issues or the test
suite, we should be fine.  I'll ping the list if I take up the cause for
something else I see wrong.

Cheers,
Na'Tosha



-- 
*Na'Tosha Bard*
Build & Infrastructure Developer | Unity Technologies

*E-Mail:* natosha at unity3d.com
*Skype:* natosha.bard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111012/545bd784/attachment.html>


More information about the Mercurial-devel mailing list