Svn subrepo status support

[Martin Geisler]

Srećko Jurić-Kavelj <jksrecko at gmail.com> writes:

> On Sat, Mar 12, 2011 at 7:32 PM, Martin Geisler <mg at lazybytes.net> wrote:
>> This patch was submitted long before we added the --subrepos flag to
>> status and many other commands. It is also quite simple since it just
>> prints the 'svn status' output -- I would expect 'hg status -S' to
>> parse and reformat the output to match the normal Mercurial output,
>> or at least to prefix the lines with the subrepository path.
>>
>> --
>> Martin Geisler
>>
>> aragost Trifork
>> Professional Mercurial support
>> http://aragost.com/mercurial/
>
> I realize that that patch was submitted long time ago. I was just
> wondering is there any special reason that there is still no status
> reporting for Subversion subrepo?

It's not something we work actively on -- I don't use subrepos myself
and only added the -S flag when a client paid me to do so.

So the answer is that we are waiting for users like yourself to send in
patches, or to pay someone to do it for you :)

> Also, there is no diff support either for Subversion or git. I'm
> planning on using Mercurial for collaborative writing of some
> documents in LaTeX, and I figured I could use SVN subrepository to
> manage binary files (images, build results, ...). Not having status
> for the SVN subrepo would confuse other users that don't have much
> experience with VCS (in this use-case example).

I agree completely that it is not optimal. Perhaps setting the
ui.commitsubrepos options to False would help here -- then Mercurial
wont recurse down to the SVN subrepos automatically.

  http://www.selenic.com/mercurial/hgrc.5.html#ui

> Before SVN subrepository idea, i considered some of binary files
> extensions. Main requirement would be that they play well with
> TortoiseHg (because of other users). It seems that snap is most
> plausible choice, but it doesn't work jet with newest
> Mercurial/TortoiseHg.

I'm surprised to hear that, I've CCed Klaus so that he can confirm if
the snap wiki front page is just outdated.

> Also, there are some new implementations for big binary files handling
> (http://selenic.com/pipermail/mercurial/2010-September/035146.html).
> Therefore, I'd like to postpone my choice for binary file handling
> extension, or use something proven/stable, like SVN subrepository.

Okay. All I know is that Klaus' company is using the snap extension in
production already for managing some very big files: their repository
sizes are in the 500 GB range from what I understand.

I still wish the authors of the big files would work on consolidating
the extensions since it would be valuable for Mercurial to ship one
standard extension for solving this problem.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/