Re: Commiting objects named .svn Was: .svn directory - safe to add files in ".svn" or ".svn/tmp"?

[Branko Čibej]

On 05.05.2014 06:56, David Balažic wrote:
> Ryan Schmidt wrote:
>> On May 4, 2014, at 15:46, David Balažic wrote:
>>
>>> Branko Čibej  wandisco.com> writes:
>>>
It's not a question of SVN being fragile or not. The .svn/ directory
is private to Subversion and you're not allowed to fiddle with it.
>>> Servus Branko,
>>>
>>> related to this, is the name ".svn" reserved/prohibited?
>>> What if I wanted to commit a bunch of files that would contain a file (or
>>> folder) named ".svn”.
>> That would not be supported. Don’t do that.
> (I'm not subscribed, BTW)
>
> I did some quick tests with TortoiseSVN 1.7.14 (based on Subversion 1.7.16) 
> and while it refuses to add/commit the name ".svn",
> I could rename an existing versioned object (both file and folder) from 
> another name to the name ".svn" and commit it (local repository).
>
> It is an old version, but if interested, someone can check this with the 
> latest software.

The subversion command-line client does not let you do this in the
working copy, but does let you rename something to ".svn" directly in
the repository. This is probably a bug ...


-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

RE: svn list support for listing directory entries only

[Bert Huijben]

The ‘list’ command is really only implemented at a high level, by retrieving 
the entries of each directory at a time and then filtering the results.

 

There is nothing you can do to really optimize this for directories without 
changing the ra layer and wire protocol for svn:// and http://.

 

I think it would make at least some users happy to add a ‘streamy’ list 
operation on the ra layer as it would optimize all the ‘svn ls’ cases, but 
nobody spend the time to fully implement this yet.

(I actually started an implementation of this some time ago, but never finished 
this as the compatibility work to support older servers was harder than I 
anticipated. But a lot of the missing ground work that made it that difficult 
back then is now implemented)

 

I’m not sure which Subversion client you use for your ‘svn ls’, but recently I 
compared an 1.6 an 1.8 client over http:// and the difference was *huge*, and 
1.9 should be slightly better yet than 1.8. Perhaps just using a newer client 
might solve your performance problem.

 

 

Note that ‘svn ls’ was never an operation that Subversion was tuned for. 
Subversion works best on and between entire trees, while ‘ls’ is mostly a 
diagnostic tool. Some api users actually use the ‘svn status’ backend to 
quickly obtain a full tree of a repository in a single request in a faster way 
than ‘ls’

 

Bert

 

From: Dan Ellis [mailto:danelli...@gmail.com] 
Sent: maandag 5 mei 2014 19:56
To: Subversion Users
Subject: Re: svn list support for listing directory entries only

 

 

 

> The "depth" parameter is used in many places, not just in "svn list"; 
> whatever enhancement you come up with must at least fit the other uses. Depth 
> was invented to describe sparse working copies, and was only later adapted to 
> other commands. For sparse working copies, "depth=dirs" probably doesn't make 
> much sense.

> Once you've defined what "depth=dirs" means for all the commands that support 
> depth, you're about 10% done ... you'd have to review the implementation for 
> every use of the depth parameter and either add "depth=dirs" semantics, or 
> make sure a reasonable error message is returned if that value is not 
> supported by a particular command: 

 



Yeah, I figured this would get shot down pretty quick since I mentioned a 
modification to a key parameter.  Completely understand and agree.  I've been 
digging around the API and I'm not sure I even see a call/parameter to fetch a 
directory listing only from the server.  Does with more knowledge of the API 
know if the API supports this, if so, any pointers (no pun intended).   I'm 
glad to call an API directly if that would work.


I'd also assume I won't get much traction with a new parameter unique to the 
list command (should it even be possible).

 

Thanks,
Dan

 

 

Re: svn list support for listing directory entries only

[Dan Ellis]

>
>
>
> The "depth" parameter is used in many places, not just in "svn list";
whatever enhancement you come up with must at least fit the other uses.
Depth was invented to describe sparse working copies, and was only later
adapted to other commands. For sparse working copies, "depth=dirs" probably
doesn't make much sense.

> Once you've defined what "depth=dirs" means for all the commands that
support depth, you're about 10% done ... you'd have to review the
implementation for every use of the depth parameter and either add
"depth=dirs" semantics, or make sure a reasonable error message is returned
if that value is not supported by a particular command:


Yeah, I figured this would get shot down pretty quick since I mentioned a
modification to a key parameter.  Completely understand and agree.  I've
been digging around the API and I'm not sure I even see a call/parameter to
fetch a directory listing only from the server.  Does with more knowledge
of the API know if the API supports this, if so, any pointers (no pun
intended).   I'm glad to call an API directly if that would work.

I'd also assume I won't get much traction with a new parameter unique to
the list command (should it even be possible).

Thanks,
Dan

Commiting objects named .svn Was: .svn directory - safe to add files in ".svn" or ".svn/tmp"?

[David Balažic]

Ryan Schmidt wrote:
> On May 4, 2014, at 15:46, David Balažic wrote:
> 
> > Branko Čibej  wandisco.com> writes:
> > 
> >>It's not a question of SVN being fragile or not. The .svn/ directory
> >>is private to Subversion and you're not allowed to fiddle with it.
> > 
> > Servus Branko,
> > 
> > related to this, is the name ".svn" reserved/prohibited?
> > What if I wanted to commit a bunch of files that would contain a file (or
> > folder) named ".svn”.
>
> That would not be supported. Don’t do that.

(I'm not subscribed, BTW)

I did some quick tests with TortoiseSVN 1.7.14 (based on Subversion 1.7.16) and 
while it refuses to add/commit the name ".svn",
I could rename an existing versioned object (both file and folder) from another 
name to the name ".svn" and commit it (local repository).

It is an old version, but if interested, someone can check this with the latest 
software.

(CCing the TSVN users list)

Regards,
David

AW: Hope subversion server can fold each 1000 revision into a zipped or compacted file.

[Markus Schaber]

Hi, Yonggang Luo,

I'm assuming you're using FSFS based repositories, as BDB repositories usually 
won't suffer from this problem.

check the documentation about repository packing:
http://svnbook.red-bean.com/en/1.8/svn.reposadmin.maint.html#svn.reposadmin.maint.diskspace.fsfspacking

Best regards

Markus Schaber

CODESYS® a trademark of 3S-Smart Software Solutions GmbH

Inspiring Automation Solutions

3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50

E-Mail: m.scha...@codesys.com | Web: 
codesys.com | CODESYS store: 
store.codesys.com
CODESYS forum: forum.codesys.com

Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade 
register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Von: 罗勇刚(Yonggang Luo) [mailto:luoyongg...@gmail.com]
Gesendet: Montag, 5. Mai 2014 14:17
An: Subversion
Betreff: Hope subversion server can fold each 1000 revision into a zipped or 
compacted file.

For really big repository, there is too much small files, that's hurt for 
backup and checksums and copy/move operations.

--
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo

Hope subversion server can fold each 1000 revision into a zipped or compacted file.

[Yonggang Luo]

For really big repository, there is too much small files, that's hurt for
backup and checksums and copy/move operations.

-- 
 此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo