I did considered using svn:needs-lock, but this property has to be set
for each single new file in my repository.
If I could set this property server-wide, or for a subfolder and all of
its descendants, it would be fine.
But setting that property for each file will lead me, someday, to a
mixture of files with needs-lock and files without it.
This will make the repository look erratic, as some changes will need
locks and another not.
Perhaps I need to read the man page for svn propset, maybe I can cron
the svn propset for the whole repository.
Felix Gilcher wrote:
>Andy Levy <mailto:andy.levy@gmail.com> schrieb am Donnerstag, 8. Dezember 2005 17:20:
>
>
>
>>On 12/8/05, Daniel Montero <danim@soin.co.cr> wrote:
>>
>>
>>> Thanks Andy. I could probably have my company wait 2-3 months,
>>> probably not half a year. You know, as svn is merge and not lock
>>> based, everybody in my department needs to do an update before
>>>modifying anything, so it is a medium problem for us.
>>>
>>>
>
>Even if it were lock-based you'd have to update you version before changing it - locks only prevent concurrent updates. But you always have the option to just update what you need (individual files, directories or partial source trees) however you might run into problems if one change depends on another somewhere else.
>
>However, you can enforce locking in svn if you prefer - see the svn:needs-lock property.
>
>
>
>>IIRC, the HTTP access is very "chatty" and it's a network overhead
>>issue (many discrete connections being opened/closed, as opposed to
>>channelling everything over one connection).
>>
>>
>>
>
>You could use a differenct access method. Some users have reported significant speed improvements after disabling on-access virus scanners (subversion walks the directory tree to determine which version of which files you currently have, this process is slowed down by on-access scanners).
>Working copies on network drives tend to be dead-slow. My working copy of 100M size with about 4300 files takes about 30sec to a minute to update using TortoiseSVN over a samba mount (even if not pulling a single file) while the same action takes about 10 seconds using the commandline client on the server. If lots of files get updated, the ration is even worse.
>
>
>
>>> So what can I do in order to accelerate the svn update for my
>>> repository. I dont want svn being so slow as it can be replaced by
>>>sourcesafe or something else if perceived as a problem.
>>>
>>>
>>More discrete updates? IOW, don't update your whole WC unless you
>>need to, just the directory you're in.
>>
>>I really hope you're joking about replacing anything with VSS. I
>>spent 6 years with VSS. You're better off with no version control at
>>all. I'll gladly take a slow update over what VSS puts you through.
>>
>>
>>
>>> Can I apply
>>> a 1.4 patch for my 1.2.3 installation ?
>>>
>>>
>>I know nothing about the Subversion source, but my gut instinct is
>>that it's nowhere near that simple.
>>
>>
>
>Even if it were that simple, you'd be more or less on your own if you introduce a bug - so I'd be careful. Your VCS is supposed to safeguard your most valuable asset, your source code and I'd not feel comfortable using a "hacked" version in production. At least test your changes properly.
>
>
>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>>For additional commands, e-mail: users-help@subversion.tigris.org
>>
>>
>
>just my $0.02
>
>felix
>
>
>
Received on Thu Dec 8 21:29:15 2005