You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Steinar Bang <sb...@dod.no> on 2008/05/16 08:36:43 UTC
Re: performance enhancement by working copy svn server
>>>>> "Ben Collins-Sussman" <su...@red-bean.com>:
> On Thu, Apr 10, 2008 at 3:43 PM, John Peacock
> <jo...@havurah-software.org> wrote:
>> Benjamin Smith-Mannschott wrote:
>>> Yuck. At first blush, this seems to me a pretty unnatural way to work.
>> Me too.
> I think hundreds of thousands of perforce users would disagree with
> you guys. ;-)
As a counter example, I am a Perforce user who still thinks it's an
unnatural way to work. I would not like to see this the default
behaviour of svn.
(But then I've never gotten really friendly with Perforce, and in my list
of Perforce annoyances, it's a fairly minor one...)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: performance enhancement by working copy svn server
Posted by Branko Čibej <br...@xbc.nu>.
Stefan Sperling wrote:
> On Sat, May 17, 2008 at 04:10:53PM -0400, Harvey, Edward wrote:
>
>> <anecdote>
>> For me in particular, this will be very welcome. I have a badly-behaved tool (from Cadence) and this is its behavior:
>> The Cadence tool assumes it owns a whole directory that you're working on.
>> It goes in, modifies all the stuff it cares to modify...
>> It finds the ".svn" directory, deletes it, and creates a ".svn" file containing only a Space char.
>> And then I'm unhappy.
>> </anecdote>
>>
>
> What a crazy tool.
>
Unfortunately those seem to be quite common on the Mac. We've had issues
open about that since before 1.0.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: performance enhancement by working copy svn server
Posted by Stefan Sperling <st...@elego.de>.
On Sat, May 17, 2008 at 04:10:53PM -0400, Harvey, Edward wrote:
> <anecdote>
> For me in particular, this will be very welcome. I have a badly-behaved tool (from Cadence) and this is its behavior:
> The Cadence tool assumes it owns a whole directory that you're working on.
> It goes in, modifies all the stuff it cares to modify...
> It finds the ".svn" directory, deletes it, and creates a ".svn" file containing only a Space char.
> And then I'm unhappy.
> </anecdote>
What a crazy tool.
I have another badly-behaved tool on my system that cannot work
recursively with Subversion working copies in a nice way,
unless I filter its output.
It's called '/usr/bin/grep' :)
Stefan
Re: performance enhancement by working copy svn server
Posted by Listman <li...@burble.net>.
On May 17, 2008, at 2:28 PM- May 17, 2008, Steinar Bang wrote:
>>>>>> Listman <li...@burble.net>:
>
>> Agreed, this is one of the advantages of Perforce, the meta-data is
>> saved on the server not in the WC and there's no chance of a
>> misbehaving tool breaking the working copy..
>
> Storing the WC on the server, is a behaviour of Perforce I would not
> like subversion to replicate. It causes problems with scaling on the
> server, and limits/complicates offline operations.
>
> (not that I think that storing the WC on the server is the plan. The
> way I've read the discussions on the list, the "single file or subdir"
> mentioned above, will be on the client machine)
Subversion's working copy gets broken regularly in our environment and
other companies I've worked. Scattering it across the filesystem is a
recipe for disaster in my experience.
The reality is that 90% of companies will put their user accounts (and
hence the Subversion meta-data) on a fileserver. Its seldom that
the .svn directories actually local to the client machine.
This idea of "offline operations" maybe useful in small, open-source
type activities, but isn't the reality in most corporations.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: performance enhancement by working copy svn server
Posted by Karl Fogel <kf...@red-bean.com>.
Steinar Bang <sb...@dod.no> writes:
> (not that I think that storing the WC on the server is the plan. The
> way I've read the discussions on the list, the "single file or subdir"
> mentioned above, will be on the client machine)
That is correct.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: performance enhancement by working copy svn server
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Listman <li...@burble.net>:
> Agreed, this is one of the advantages of Perforce, the meta-data is
> saved on the server not in the WC and there's no chance of a
> misbehaving tool breaking the working copy..
Storing the WC on the server, is a behaviour of Perforce I would not
like subversion to replicate. It causes problems with scaling on the
server, and limits/complicates offline operations.
(not that I think that storing the WC on the server is the plan. The
way I've read the discussions on the list, the "single file or subdir"
mentioned above, will be on the client machine)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: performance enhancement by working copy svn server
Posted by Listman <li...@burble.net>.
On May 17, 2008, at 1:10 PM- May 17, 2008, Harvey, Edward wrote:
>>> I think the general consensus is that the default svn behavior will
>>> not change; 'svn edit' will be an optional mode of working,
>> for those
>>> who want or need the speed tradeoff.
>>
>> I figured that from later postings in the thread, but it's
>> good to see it spelled out clear.
>
> Correct, the default behavior will not change - 'svn edit' remains
> optional.
>
> However, the WC backend is likely to change. Consolidating all
> the .svn subdirs into a single file, or into a single dir.
>
> <anecdote>
> For me in particular, this will be very welcome. I have a badly-
> behaved tool (from Cadence) and this is its behavior:
> The Cadence tool assumes it owns a whole directory that
> you're working on.
> It goes in, modifies all the stuff it cares to modify...
> It finds the ".svn" directory, deletes it, and creates a
> ".svn" file containing only a Space char.
> And then I'm unhappy.
> </anecdote>
Agreed, this is one of the advantages of Perforce, the meta-data is
saved on the server not in the WC and there's no chance of a
misbehaving tool breaking the working copy.. As one of my users said
the other day, Perforce is "bullet-proof", Subversion is fragile..
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: performance enhancement by working copy svn server
Posted by "Harvey, Edward" <Ed...@patni.com>.
> > I think the general consensus is that the default svn behavior will
> > not change; 'svn edit' will be an optional mode of working,
> for those
> > who want or need the speed tradeoff.
>
> I figured that from later postings in the thread, but it's
> good to see it spelled out clear.
Correct, the default behavior will not change - 'svn edit' remains optional.
However, the WC backend is likely to change. Consolidating all the .svn subdirs into a single file, or into a single dir.
<anecdote>
For me in particular, this will be very welcome. I have a badly-behaved tool (from Cadence) and this is its behavior:
The Cadence tool assumes it owns a whole directory that you're working on.
It goes in, modifies all the stuff it cares to modify...
It finds the ".svn" directory, deletes it, and creates a ".svn" file containing only a Space char.
And then I'm unhappy.
</anecdote>
This e-mail message may contain proprietary, confidential or legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify us immediately at netadmin@patni.com and delete this mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: performance enhancement by working copy svn server
Posted by Steinar Bang <sb...@dod.no>.
>>>>> "Ben Collins-Sussman" <su...@red-bean.com>:
> I think the general consensus is that the default svn behavior will
> not change; 'svn edit' will be an optional mode of working, for those
> who want or need the speed tradeoff.
I figured that from later postings in the thread, but it's good to see
it spelled out clear.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: performance enhancement by working copy svn server
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Fri, May 16, 2008 at 3:36 AM, Steinar Bang <sb...@dod.no> wrote:
>>>>>> "Ben Collins-Sussman" <su...@red-bean.com>:
>
>> On Thu, Apr 10, 2008 at 3:43 PM, John Peacock
>> <jo...@havurah-software.org> wrote:
>>> Benjamin Smith-Mannschott wrote:
>
>>>> Yuck. At first blush, this seems to me a pretty unnatural way to work.
>
>>> Me too.
>
>> I think hundreds of thousands of perforce users would disagree with
>> you guys. ;-)
>
> As a counter example, I am a Perforce user who still thinks it's an
> unnatural way to work. I would not like to see this the default
> behaviour of svn.
I think the general consensus is that the default svn behavior will
not change; 'svn edit' will be an optional mode of working, for those
who want or need the speed tradeoff.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org