You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Neels J Hofmeyr <ne...@elego.de> on 2008/10/24 21:28:07 UTC
svn edit
Ben Collins-Sussman wrote:
> Or, just wait for the working-copy rewrite (in progress now) to
> implement an 'svn edit' command. No more crawling the working copy at
> all.
Say, what?
Got a pointer for me that explains it?
Thanks
~Neels
--
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696 mobile: +49 177 2345869 fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
RE: svn edit
Posted by Bert Huijben <B....@competence.biz>.
From: Listman [mailto:listman@burble.net]
> Sent: zondag 26 oktober 2008 19:50
> To: Hyrum K. Wright; Erik Huelsmann
> Cc: Jens Seidel; dev@subversion.tigris.org; Edward Harvey
> Subject: Re: svn edit
> BTW: for the poster that thought p4 is some obscure, irrelevant tool
you're
> very wrong. Just ask the 3k(+) at Google and the 500k users worldwide.
And I think this would give some comparison (posted today on the
TortoiseSVN log)
(http://tortoisesvn.net/node/349)
========
The intervals between millions are getting shorter. Looks like we are
constantly having > 500.000 downloads per month now.
========
My best guess would be that TortoiseSVN is the most popular Subversion
client in numbers, but that would give subversion at least half a
million Windows users per month, probably a lot more.
The number of downloads is just some indication; with AnkhSVN we see
quite a difference in real users checking for updates and the number of
downloads; the number of installations is probably higher as it is very
easy to deploy TortoiseSVN from a single installation through an entire
organization.
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Listman <li...@burble.net>.
On Oct 26, 2008, at 9:03 AM- Oct 26, 2008, Harvey, Edward wrote:
>>> When you want to edit a file, you run 'svn edit file', which makes
>> the
>>> file read-write and registers this fact in sqlite. Then, when you
>> run
>>
>> If I would be required to call svn [edit] I would stop using
>> Subversion
>
> You won't be forced to use it, it's optional, for the purpose of
> gaining performance. By comparison, getting status on a directory
> that takes 5-10 mins in svn will be nearly instant (less than 1 sec)
> on perforce. That's the performance gain that svn will be able to
> achieve by using "svn edit"
>
>
>> Isn't this a problem of the filesystem if comparing file modification
>> times is
>> so slow? Is there really no filesystem (Reiser, ext3/4, XFS, ...)
>> which
>
> If you have tens of thousands of versioned files in your working
> copy, regardless of how fast your filesystem is, it takes a
> significant time to walk the tree scanning for stuff that changed.
> Which must be done on every "svn status" and "svn update" etc.
>
> For my users, it takes 5-10 minutes every time they "svn status"
> their WC. As long as the cache is cold (and it usually is because
> the system is busy working on peoples' files too besides just
> versioning them). On a warm cache it's 20-30 sec, but there's no
> reasonable way to keep the cache warm.
This is the kind of performance issue that I was hinting at in the
thread from a couple of days ago "Re: Subversion Performance (was Re:
fs-rep-sharing branch)"
As I said before, performance is the biggest issue facing Subversion
today. Lets think very hard before we introduce any improvements that
make things any worse than they already are. For centralized SCM
Perforce is our only real competition, but there's absolutely no
reason why we can't get at least as good as them. The "svn edit"
optional command will get us 90% of the way actually.
BTW: for the poster that thought p4 is some obscure, irrelevant tool
you're very wrong. Just ask the 3k(+) at Google and the 500k users
worldwide.
Thx again.
Re: svn edit
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Harvey, Edward wrote:
>>> When you want to edit a file, you run 'svn edit file', which makes
>> the
>>> file read-write and registers this fact in sqlite. Then, when you
>> run
>>
>> If I would be required to call svn [edit] I would stop using Subversion
>
> You won't be forced to use it, it's optional, for the purpose of gaining performance. By comparison, getting status on a directory that takes 5-10 mins in svn will be nearly instant (less than 1 sec) on perforce. That's the performance gain that svn will be able to achieve by using "svn edit"
[Note: I personally don't find the idea of 'svn edit' very palatable, but can
understand why others would.]
I think we have a long way to go toward improving the current method of doing
things (i.e., wc-ng), and suggest that we pursue those avenues before going off
into uncharted territory. We should be doing comparisons against the
new-and-improved code (when ready) to see how much the current behavior can be
attributed to an old working copy library.
>
>> Isn't this a problem of the filesystem if comparing file modification
>> times is
>> so slow? Is there really no filesystem (Reiser, ext3/4, XFS, ...) which
>
> If you have tens of thousands of versioned files in your working copy, regardless of how fast your filesystem is, it takes a significant time to walk the tree scanning for stuff that changed. Which must be done on every "svn status" and "svn update" etc.
I can understand why 'svn status' crawls the filesystem, but 'svn update'? It's
just replaying an editor drive from the repository and applying those changes
locally. I would think that the costs in update aren't filesystem crawls, but
rather the I/O associated with doing the update, updating the pristine copies,
and working with the entries file. Some of this is just the cost of doing an
update, and some of it will be improved through the use of the new working copy
library. (Disclaimer: it's been a while since I've been in the 'svn up' code.)
Again, let's see how current improvements work out before rushing off to add new
features which cover up, not fix, the underlying problems.
-Hyrum
RE: svn edit
Posted by "Harvey, Edward" <Ed...@patni.com>.
> > When you want to edit a file, you run 'svn edit file', which makes
> the
> > file read-write and registers this fact in sqlite. Then, when you
> run
>
> If I would be required to call svn [edit] I would stop using Subversion
You won't be forced to use it, it's optional, for the purpose of gaining performance. By comparison, getting status on a directory that takes 5-10 mins in svn will be nearly instant (less than 1 sec) on perforce. That's the performance gain that svn will be able to achieve by using "svn edit"
> Isn't this a problem of the filesystem if comparing file modification
> times is
> so slow? Is there really no filesystem (Reiser, ext3/4, XFS, ...) which
If you have tens of thousands of versioned files in your working copy, regardless of how fast your filesystem is, it takes a significant time to walk the tree scanning for stuff that changed. Which must be done on every "svn status" and "svn update" etc.
For my users, it takes 5-10 minutes every time they "svn status" their WC. As long as the cache is cold (and it usually is because the system is busy working on peoples' files too besides just versioning them). On a warm cache it's 20-30 sec, but there's no reasonable way to keep the cache warm.
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: svn edit
Posted by Jens Seidel <je...@users.sf.net>.
Hi,
On Fri, Oct 24, 2008 at 05:16:22PM -0500, Ben Collins-Sussman wrote:
> I have no thread handy, but it's been discussed over and over in the
> wc-ng design as an 'eventual feature' to be implemented. It's
I also do not remember reading about svn edit before.
> basically imitating perforce: the entire working copy is read-only.
There exist so many free version control systems never mentioned on this
list that I really wonder why people use commercial ones most never
heard of.
> When you want to edit a file, you run 'svn edit file', which makes the
> file read-write and registers this fact in sqlite. Then, when you run
If I would be required to call svn add I would stop using Subversion and
switch to quilt. It has the advantage of allowing me to change previous
patches. I still hope git has this feature as well (and I think this applies
to mercurial as well) but I never found the time to properly learn it :-(
> 'svn status', 'svn diff', 'svn commit', etc. there's no need to crawl
> the tree trying to discover local edits; you just ask the database
> which files to stat. It makes things shockingly fast, and while it
> sounds horribly annoying and restrictive to a veteran CVS or SVN user,
> it's actually a really nice way to work.
The following may be a naive question and I really don't know this topic
very well, nevertheless it wasn't dicussed before and could give you some
hints:
Isn't this a problem of the filesystem if comparing file modification times is
so slow? Is there really no filesystem (Reiser, ext3/4, XFS, ...) which allows
fast access to this information? Or do you fear using filesystem specific
attributes for the working copy (such as sorting files via modification time)
(if they exist at all)?
Why don't you write down the preferred filesystem parameters, suggest users the
best one for Subversion and file wishlist bugs for still missing features?
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Kevin Grover <ke...@kevingrover.net>.
You can actually configure CVS to work this way also: you need 'cvs edit' or
(C-x q in Emacs VC Mode) to set a file to editable (sets the write attribute
and registers it in the history - if so configured). It's the way I have an
old CVS server set up. It's not really a problem at all (at least for any
of us it wasn't)
Now, we _very_ rarely use that repository. I would have long ago converted
the it to svn, but for the life of me could not get svn to compile on that
machine (very old, AIX 4.1.2, gcc 3.8.x, ...).
On Fri, Oct 24, 2008 at 3:16 PM, Ben Collins-Sussman
<su...@red-bean.com>wrote:
> I have no thread handy, but it's been discussed over and over in the
> wc-ng design as an 'eventual feature' to be implemented. It's
> basically imitating perforce: the entire working copy is read-only.
> When you want to edit a file, you run 'svn edit file', which makes the
> file read-write and registers this fact in sqlite. Then, when you run
> 'svn status', 'svn diff', 'svn commit', etc. there's no need to crawl
> the tree trying to discover local edits; you just ask the database
> which files to stat. It makes things shockingly fast, and while it
> sounds horribly annoying and restrictive to a veteran CVS or SVN user,
> it's actually a really nice way to work.
>
>
> On Fri, Oct 24, 2008 at 4:28 PM, Neels J Hofmeyr <ne...@elego.de> wrote:
> >
> >
> > Ben Collins-Sussman wrote:
> >> Or, just wait for the working-copy rewrite (in progress now) to
> >> implement an 'svn edit' command. No more crawling the working copy at
> >> all.
> >
> > Say, what?
> > Got a pointer for me that explains it?
> >
> > Thanks
> > ~Neels
> >
> > --
> > Neels Hofmeyr -- elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> > phone: +49 30 23458696 mobile: +49 177 2345869 fax: +49 30 23458695
> > http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> > Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Re: svn edit
Posted by Peter Samuelson <pe...@p12n.org>.
[Blair Zajac]
> Are there any other open-source version control systems that use the
> read-only model? Isn't the reason 'p4 edit' is needed is to indicate to
> the server the intentions to edit the file, which svn doesn't need?
Not really a version control system, but ... there is 'quilt', a system
for managing a stack of patches to an upstream project. It is lazy
about making backups of files you're editing in the current patch, so
there is an 'edit' command (actually 'quilt add') to ensure that it has
a pristine copy of a file.
I thought I wouldn't like it, but I've gotten used to it. Though it
helps that you can import an existing udiff patch using a different
quilt command.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Blair Zajac <bl...@orcaware.com>:
> Ben Collins-Sussman wrote:
>> ... It's basically imitating perforce: the entire working copy is
>> read-only. When you want to edit a file, you run 'svn edit file',
>> which makes the file read-write and registers this fact in sqlite.
> Have we decided that this is something we really want?
I'm an unwilling and unhappy perforce user, and I don't want to see this
behaviour in perforce as well.
> It does sound very annoying and restrictive.
It is very annoying for code versioning, especially when IDE tools start
changing files without doing "p4 edit".
Things can become very messy (IDEs of experience: eclipse and Visual
Studio. Both are bad, but VS and perforce are the worst).
It is very restrictive for one of my use cases, which is version control
of my unix/linux home control. There I empathically _don't_ want this.
For this use cse I like the fact that SVN stores the actual access on
the files, and can recreate that.
Bad, bad, bad! Please don't do it!
- Steinar
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Philipp Marek <ph...@emerion.com>.
On Wednesday, 29. October 2008, Greg Stein wrote:
> Cool. That would be around my expectation for our performance in
> wc-ng: just a quick walk of the tree calling lstat(), looking for size
> changes or timestamp changes.
Right.
> Also, recall that I had planned to have a mode for 'svn stat' that
> only looks at the metadata (adds, removes, etc), but without a crawl.
> I didn't think a simple crawl would be so fast.
Well, it ain't.
FSVS uses it's (supposed) complete knowledge about all (versioned) entries in
the working copy to build the entry list *sorted* - by device and inode, so
that the harddisk needn't seek so much.
That makes it faster than find.
> I think, for now, that
> I'm going to punt on the idea of a no-crawl status mode. No reason to
> monkey up status with Yet Another Command Line Switch when it can go
> this fast (and think about the typical case!).
Well, of course it depends on your storage too.
> And think about hot caches! My Macbook can "find . | wc -l" across
> 170k files in just 5 seconds.
Hot caches help a bit; but then FSVS is slower than find, as it does
additional processing.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Philipp Marek <ph...@emerion.com>.
On Wednesday, 29. October 2008, Listman wrote:
> On Oct 29, 2008, at 5:00 AM- Oct 29, 2008, Greg Stein wrote:
> > And think about hot caches! My Macbook can "find . | wc -l" across
> > 170k files in just 5 seconds.
> you can't count on the cache being hot at all. i spend most of my time
> working on a compute server with several other coworkers, the kernel
> cache is shared amongst lots of apps, not just svn. i very rarely get
> lucky with hot cache svn status. this is the norm for all the
> companies i consult with in the silicon valley area.
But at least the inode cache should get much better as soon as the .svn
directories disappear - that should more than half the number of inodes in
use.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Wed, Oct 29, 2008 at 2:39 PM, Greg Stein <gs...@gmail.com> wrote:
> I've got some coding time coming up over the next 4-5 days, leading up
> to ApacheCon. Of course, New Orleans might distract me a bit :-P
> (thankfully, I've been a tourist there a few times, so I'll probably
> just plant at a bar with laptop and code rather than go sightsee).
Save a seat for me as I plan to do some Subversion hacking too - that
is, if I don't get distracted by Fallout 3. *ahem*
Notably something in trunk is causing ra_serf to act funny for me that
I want to track down - saving/reuse of server certs is busted and I'm
getting lots of double free errors after updates/commits. Once I sort
that out, if you want some help with wc stuff, I can probably lend a
hand.
(I was supposed to do some stuff Sat/Sun, but I think I've mostly
gotten out of those commitments.) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Oct 29, 2008 at 11:24 AM, Listman <li...@burble.net> wrote:
>...
> right, its clear 1.6 is way too early for the WC rewrite. I was referring to
> this
> email from Greg Oct 1st:
>
>> Re-reading your original email...
>>
>> The new API allows for compressing the text base files. Pretty much
>> transparently. So yah... there could be improvements.
>>
>> But I still maintain that it doesn't matter. 1.6 comes with a lot of
>> improvements, and it needs sqlite.
>>
>> Inside, we start moving towards a maintainable WC library, which
>> everybody has wanted for something like three years now. So my opinion
>> is pretty much "done deal" unless there is a better way to make some
>> steps towards a cleaner WC library.
>
> which i took to mean that the 1.6 release includes sqlite and *some*
> improvements.
>
> i'm not trying to pin anyone down, just wondering if i should get ready for
> copious
> amounts of testing on the 1.6 branch..
So far, I've just been slamming code around, trying to get it into a
place where I *could* add in some of the new pristine stuff and the
sqlite work. It's been slow going with some of the travel that I've
done. I got some good work done in Brussels while my gf was off
working, but there is still a good chunk to do.
I've got some coding time coming up over the next 4-5 days, leading up
to ApacheCon. Of course, New Orleans might distract me a bit :-P
(thankfully, I've been a tourist there a few times, so I'll probably
just plant at a bar with laptop and code rather than go sightsee).
So. If things go well, then sure. I could have some stuff ready for
the 1.6 branch. Best case, we'll have new pristine files with some
info stored into the sqlite database.
No compression tho. And no properties in the sqlite database.
That's my basic expectation now. I'd probably shoot for properties
before compression. And that "no" is only my expectation, rather than
a hard line :-P
If things go not-well, then we'll just have some cleaned up WC code
with some reduced I/O and checksum'ing.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Listman <li...@burble.net>.
On Oct 29, 2008, at 10:42 AM- Oct 29, 2008, Mark Phippard wrote:
> On Wed, Oct 29, 2008 at 1:31 PM, Listman <li...@burble.net> wrote:
>>
>> On Oct 29, 2008, at 5:00 AM- Oct 29, 2008, Greg Stein wrote:
>>
>>> Cool. That would be around my expectation for our performance in
>>> wc-ng: just a quick walk of the tree calling lstat(), looking for
>>> size
>>> changes or timestamp changes.
>>
>>> Also, recall that I had planned to have a mode for 'svn stat' that
>>> only looks at the metadata (adds, removes, etc), but without a
>>> crawl.
>>> I didn't think a simple crawl would be so fast. I think, for now,
>>> that
>>> I'm going to punt on the idea of a no-crawl status mode. No reason
>>> to
>>> monkey up status with Yet Another Command Line Switch when it can go
>>> this fast (and think about the typical case!).
>>>
>>> And think about hot caches! My Macbook can "find . | wc -l" across
>>> 170k files in just 5 seconds.
>>>
>>
>> you can't count on the cache being hot at all. i spend most of my
>> time
>> working on a compute server with several other coworkers, the
>> kernel cache
>> is shared amongst lots of apps, not just svn. i very rarely get
>> lucky with
>> hot cache svn status. this is the norm for all the companies i
>> consult with
>> in the silicon valley area.
>>
>> so greg, will i be able to start testing any of this when the 1.6
>> branch
>> comes along? will most of your changes be in there by then?
>
> The WC rewrite is not part of the 1.6 release. I think in another
> email he suggested that trunk would hopefully start having some of
> these changes in January.
right, its clear 1.6 is way too early for the WC rewrite. I was
referring to this
email from Greg Oct 1st:
> Re-reading your original email...
>
> The new API allows for compressing the text base files. Pretty much
> transparently. So yah... there could be improvements.
>
> But I still maintain that it doesn't matter. 1.6 comes with a lot of
> improvements, and it needs sqlite.
>
> Inside, we start moving towards a maintainable WC library, which
> everybody has wanted for something like three years now. So my opinion
> is pretty much "done deal" unless there is a better way to make some
> steps towards a cleaner WC library.
which i took to mean that the 1.6 release includes sqlite and *some*
improvements.
i'm not trying to pin anyone down, just wondering if i should get
ready for copious
amounts of testing on the 1.6 branch..
thx
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Oct 29, 2008 at 1:31 PM, Listman <li...@burble.net> wrote:
>
> On Oct 29, 2008, at 5:00 AM- Oct 29, 2008, Greg Stein wrote:
>
>> Cool. That would be around my expectation for our performance in
>> wc-ng: just a quick walk of the tree calling lstat(), looking for size
>> changes or timestamp changes.
>
>> Also, recall that I had planned to have a mode for 'svn stat' that
>> only looks at the metadata (adds, removes, etc), but without a crawl.
>> I didn't think a simple crawl would be so fast. I think, for now, that
>> I'm going to punt on the idea of a no-crawl status mode. No reason to
>> monkey up status with Yet Another Command Line Switch when it can go
>> this fast (and think about the typical case!).
>>
>> And think about hot caches! My Macbook can "find . | wc -l" across
>> 170k files in just 5 seconds.
>>
>
> you can't count on the cache being hot at all. i spend most of my time
> working on a compute server with several other coworkers, the kernel cache
> is shared amongst lots of apps, not just svn. i very rarely get lucky with
> hot cache svn status. this is the norm for all the companies i consult with
> in the silicon valley area.
>
> so greg, will i be able to start testing any of this when the 1.6 branch
> comes along? will most of your changes be in there by then?
The WC rewrite is not part of the 1.6 release. I think in another
email he suggested that trunk would hopefully start having some of
these changes in January.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> On Thu, Oct 30, 2008 at 1:19 PM, Branko Čibej <br...@xbc.nu> wrote:
>
>> Harvey, Edward wrote:
>>
>>> For a simple "find" I think this is typical performance:
>>>
>>> 100,000 files in 10 sec cold cache
>>> 1,000,000 files in 3 sec warm cache.
>>>
>>> I think if this performance can be achieved for "svn st" and "svn up" it's acceptable. I do, however, doubt being able to achieve that while walking the tree with svn - because git failed to achieve it.
>>>
>> Oh I say, that's a truly obnoxious statement. Second of all, a version
>> control system has a lot more to do than a simple find. But first of
>> all, it implies that git is the unattainable grail of software
>> perfection. Perish the thought.
>>
>
> Brane: clearly you're both ugly and stupid. :-)
>
Yup, and I prefer it that way. :-P
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Listman <li...@burble.net>.
On Oct 30, 2008, at 12:34 PM- Oct 30, 2008, Harvey, Edward wrote:
>> On Thu, Oct 30, 2008 at 1:19 PM, Branko Čibej <br...@xbc.nu> wrote:
>>> Harvey, Edward wrote:
>>>> For a simple "find" I think this is typical performance:
>>>>
>>>> 100,000 files in 10 sec cold cache
>>>> 1,000,000 files in 3 sec warm cache.
>>>>
>>>> I think if this performance can be achieved for "svn st"
>> and "svn up" it's acceptable. I do, however, doubt being
>> able to achieve that while walking the tree with svn -
>> because git failed to achieve it.
>>>
>>> Oh I say, that's a truly obnoxious statement. Second of
>> all, a version
>>> control system has a lot more to do than a simple find. But
>> first of
>>> all, it implies that git is the unattainable grail of software
>>> perfection. Perish the thought.
>>
>> Brane: clearly you're both ugly and stupid. :-)
>
> Alright, let's just cool it everyone. There is a little bit of
> truth all around.
Don't worry, Sussman is just parodying Linus ;) FUNNY!
RE: svn edit
Posted by "Harvey, Edward" <Ed...@patni.com>.
> On Thu, Oct 30, 2008 at 1:19 PM, Branko Čibej <br...@xbc.nu> wrote:
> > Harvey, Edward wrote:
> >> For a simple "find" I think this is typical performance:
> >>
> >> 100,000 files in 10 sec cold cache
> >> 1,000,000 files in 3 sec warm cache.
> >>
> >> I think if this performance can be achieved for "svn st"
> and "svn up" it's acceptable. I do, however, doubt being
> able to achieve that while walking the tree with svn -
> because git failed to achieve it.
> >
> > Oh I say, that's a truly obnoxious statement. Second of
> all, a version
> > control system has a lot more to do than a simple find. But
> first of
> > all, it implies that git is the unattainable grail of software
> > perfection. Perish the thought.
>
> Brane: clearly you're both ugly and stupid. :-)
Alright, let's just cool it everyone. There is a little bit of truth all around.
It's true a versioning system *does* have a lot more to do than simply peek at all the files, and that's why both git and svn take an order of magnitude longer to walk a tree than a simple tree walker. The versioning system must perform "open" and "read" and "seek" or whatever operations... And do some thinking... This is why I am a skeptic about svn or git or anyone being able to come close to the performance of simply walking the tree. But there is still a lot of ground to be gained in terms of performance boosting.
Git developers & users are proud of their performance, and Linus is one of them. So whatever inefficiencies they have, I'm sure it's not blatant and shameful. This is why I think the performance of git is a realistic upper-bound expectation for performance of a versioning tool that walks the tree. Maybe it can be beat. But it's doubtfully an order of magnitude.
Then again, if the WC metadata were in ram already, the most expensive thing remaining would be to walk the tree. So theoretically it might be possible to achieve the tree-walking performance of a simple tree walker. Nobody here has tried it yet (AFAIK).
So let's agree to let the WC NG come about, and see how well it does. If it somehow destroys the performance of git, and comes close to the speed of a simple walk, then probably nobody will have any further complaints.
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: svn edit
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Thu, Oct 30, 2008 at 1:19 PM, Branko Čibej <br...@xbc.nu> wrote:
> Harvey, Edward wrote:
>> For a simple "find" I think this is typical performance:
>>
>> 100,000 files in 10 sec cold cache
>> 1,000,000 files in 3 sec warm cache.
>>
>> I think if this performance can be achieved for "svn st" and "svn up" it's acceptable. I do, however, doubt being able to achieve that while walking the tree with svn - because git failed to achieve it.
>
> Oh I say, that's a truly obnoxious statement. Second of all, a version
> control system has a lot more to do than a simple find. But first of
> all, it implies that git is the unattainable grail of software
> perfection. Perish the thought.
Brane: clearly you're both ugly and stupid. :-)
Re: svn edit
Posted by Branko Čibej <br...@xbc.nu>.
Harvey, Edward wrote:
> For a simple "find" I think this is typical performance:
>
> 100,000 files in 10 sec cold cache
> 1,000,000 files in 3 sec warm cache.
>
> I think if this performance can be achieved for "svn st" and "svn up" it's acceptable. I do, however, doubt being able to achieve that while walking the tree with svn - because git failed to achieve it.
Oh I say, that's a truly obnoxious statement. Second of all, a version
control system has a lot more to do than a simple find. But first of
all, it implies that git is the unattainable grail of software
perfection. Perish the thought.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn edit
Posted by "Harvey, Edward" <Ed...@patni.com>.
> On Oct 29, 2008, at 5:00 AM- Oct 29, 2008, Greg Stein wrote:
> > And think about hot caches! My Macbook can "find . | wc -l" across
> > 170k files in just 5 seconds.
> >
>
> you can't count on the cache being hot at all. i spend most
For a simple "find" I think this is typical performance:
100,000 files in 10 sec cold cache
1,000,000 files in 3 sec warm cache.
I think if this performance can be achieved for "svn st" and "svn up" it's acceptable. I do, however, doubt being able to achieve that while walking the tree with svn - because git failed to achieve it. But I'll happily wait around for svn to give it a try, and discuss it later.
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: svn edit
Posted by Listman <li...@burble.net>.
On Oct 29, 2008, at 5:00 AM- Oct 29, 2008, Greg Stein wrote:
> Cool. That would be around my expectation for our performance in
> wc-ng: just a quick walk of the tree calling lstat(), looking for size
> changes or timestamp changes.
> Also, recall that I had planned to have a mode for 'svn stat' that
> only looks at the metadata (adds, removes, etc), but without a crawl.
> I didn't think a simple crawl would be so fast. I think, for now, that
> I'm going to punt on the idea of a no-crawl status mode. No reason to
> monkey up status with Yet Another Command Line Switch when it can go
> this fast (and think about the typical case!).
>
> And think about hot caches! My Macbook can "find . | wc -l" across
> 170k files in just 5 seconds.
>
you can't count on the cache being hot at all. i spend most of my time
working on a compute server with several other coworkers, the kernel
cache is shared amongst lots of apps, not just svn. i very rarely get
lucky with hot cache svn status. this is the norm for all the
companies i consult with in the silicon valley area.
so greg, will i be able to start testing any of this when the 1.6
branch comes along? will most of your changes be in there by then?
thx!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Greg Stein <gs...@gmail.com>.
Cool. That would be around my expectation for our performance in
wc-ng: just a quick walk of the tree calling lstat(), looking for size
changes or timestamp changes.
Also, recall that I had planned to have a mode for 'svn stat' that
only looks at the metadata (adds, removes, etc), but without a crawl.
I didn't think a simple crawl would be so fast. I think, for now, that
I'm going to punt on the idea of a no-crawl status mode. No reason to
monkey up status with Yet Another Command Line Switch when it can go
this fast (and think about the typical case!).
And think about hot caches! My Macbook can "find . | wc -l" across
170k files in just 5 seconds.
Thanks,
-g
On Wed, Oct 29, 2008 at 1:02 AM, Philipp Marek
<ph...@emerion.com> wrote:
> On Tuesday, 28. October 2008, Harvey, Edward wrote:
>> I'm not sure what you mean by "with full caches" or "keep access more
>> local" but I do know this - I created a similar python script to walk a
>> tree.
>> With cold cache, local disk, python walking the tree on 100,000
>> files takes approx 10 sec With cold cache, local disk, "svn stat" on 17,000
>> files (50,000 including .svn dirs) takes approx 4 mins With cold cache,
>> local disk, "git status" on 17,000 files (30,000 including .git dirs) takes
>> approx 2 mins Perforce is able to do this is zero time. (a few ms)
> In case anybody's interested, here are some performance numbers for FSVS -
> which walks the whole tree, too.
>
>
> Example: ~22K files, notebook (slow harddisk) with 1.6GHz CPU, cold cache,
> entries known (so a checkout, and not a completely new import); FSVS uses no
> .svn dirs:
>
> dolly:/example# find . | wc -l
> 22147
> # Clear cache
> dolly:/example# echo 3 > /proc/sys/vm/drop_caches
> # fsvs with cold cache, but using a sorted list of existing entries -
> # harddisk doesn't need to seek as much
> dolly:/example# time fsvs st > /dev/null
>
> real 0m6.000s
> user 0m0.240s
> sys 0m0.372s
>
> (This was taken from the documentation at
> http://fsvs.tigris.org/source/browse/fsvs/trunk/fsvs/doc/PERFORMANCE?rev=972&view=markup)
>
> If someone wants to know numbers for some "enterprise" machines (raid), I can
> provide them, too.
>
>
> Regards,
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Philipp Marek <ph...@emerion.com>.
On Tuesday, 28. October 2008, Harvey, Edward wrote:
> I'm not sure what you mean by "with full caches" or "keep access more
> local" but I do know this - I created a similar python script to walk a
> tree.
> With cold cache, local disk, python walking the tree on 100,000
> files takes approx 10 sec With cold cache, local disk, "svn stat" on 17,000
> files (50,000 including .svn dirs) takes approx 4 mins With cold cache,
> local disk, "git status" on 17,000 files (30,000 including .git dirs) takes
> approx 2 mins Perforce is able to do this is zero time. (a few ms)
In case anybody's interested, here are some performance numbers for FSVS -
which walks the whole tree, too.
Example: ~22K files, notebook (slow harddisk) with 1.6GHz CPU, cold cache,
entries known (so a checkout, and not a completely new import); FSVS uses no
.svn dirs:
dolly:/example# find . | wc -l
22147
# Clear cache
dolly:/example# echo 3 > /proc/sys/vm/drop_caches
# fsvs with cold cache, but using a sorted list of existing entries -
# harddisk doesn't need to seek as much
dolly:/example# time fsvs st > /dev/null
real 0m6.000s
user 0m0.240s
sys 0m0.372s
(This was taken from the documentation at
http://fsvs.tigris.org/source/browse/fsvs/trunk/fsvs/doc/PERFORMANCE?rev=972&view=markup)
If someone wants to know numbers for some "enterprise" machines (raid), I can
provide them, too.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Oct 28, 2008 at 10:01 AM, Ben Collins-Sussman
<su...@red-bean.com> wrote:
>...
> Whatever the case, the rewrite of libsvn_wc is what gstein is working
> on now, and is highest priority. This whole 'svn edit' thing is just
> a pie-in-the-sky thing that we'd like to add (as a strictly *optional*
> mode) long after libsvn_wc2 has stabilized. No need to get excited
> about it for now.
Right. And I agree with Hyrum: I suspect that we're going to see a LOT
faster improvement across the board. The driving force behind "svn
edit" might just disappear for almost all but the most extreme working
copies. (and you know my views on making that final few percent of
users happy)
So. Let's see where we end up with 1.7. It'll be some time around
January before we'll notice any real performance gains, so just sit
tight people.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> On Tue, Oct 28, 2008 at 12:33 PM, Branko Čibej <br...@xbc.nu> wrote:
>
>> Still, the idea that you have to explicitly tell your wc that you're
>> modifying a file is abominable.
>>
>
> I used to think that too, but really... how is it any worse that
> having to run 'svn add', 'svn rm', 'svn cp', 'svn mv', 'svn mkdir'?
> :-) If anything, one could argue that svn is inconsistent in that we
> have to explicitly yell our intentions to libsvn_wc about everything
> we do *except* editing file contents. A number of svn newbies have
> been confused by this, and we had to point it out in the book.
>
> Honestly, the idea of an 'edit' command used to be appalling to me,
> but after three years of using perforce I find that it's not a burden
> at all. Not even noticeable. When working on code, the act of
> "beginning edits on a file" just doesn't happen that often. It
> happens on a handful of files exactly once when you begin the task,
> and then that's it. The cost of running 'svn edit' (or C-x,c-q in
> emacs) is a drop in the ocean compared to the amount of time spent on
> the coding and debugging. It becomes as transparent as all of your
> other interaction with the version control system.
>
Well, de gustibus non disputandum est, however, you'll admit that
getting used to something tends to skew the objectivity somewhat. I used
to have to same sort of twinges about not locking files when moving from
RCS to CVS ... and got used to it ... *but* then had to use ClearCase in
lock-modify-unlock mode and was not happy at all.
At one point I did enforce "cvs edit" on a project. It worked for about
a month, then people found out that a certain well-known editor could be
told to silently overwrite read-only files in certain directories. *splat*!
Since we've all agreed to wait for speed improvements to happen, let's
wait. :)
-- Brane
P.S.: With a inotify-like daemon you don't need "svn mv" and such any
more. :-P
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Tue, Oct 28, 2008 at 12:19 PM, Harvey, Edward
<Ed...@patni.com> wrote:
> Out of curiosity, can you name something specific, like "chrome has 50,000 files excluding .svn directories" or something like that?
>
You can checkout the chrome source yourself right now:
http://src.chromium.org/svn/trunk
Subversion's own source tree is about 30MB (excluding .svn dirs):
approximately 1500 files and 175 directories. With a cold cache, it
takes me 5 seconds to run 'svn status', and with a warm cache it takes
0.1 seconds.
Chrome's source tree is about 1.2GB (excluding .svn dirs). With a
cold cache it takes 40 seconds to run 'svn status' and with a warm
cache it takes about 25 seconds. This is not trivial.
On Tue, Oct 28, 2008 at 12:33 PM, Branko Čibej <br...@xbc.nu> wrote:
> Still, the idea that you have to explicitly tell your wc that you're
> modifying a file is abominable.
I used to think that too, but really... how is it any worse that
having to run 'svn add', 'svn rm', 'svn cp', 'svn mv', 'svn mkdir'?
:-) If anything, one could argue that svn is inconsistent in that we
have to explicitly yell our intentions to libsvn_wc about everything
we do *except* editing file contents. A number of svn newbies have
been confused by this, and we had to point it out in the book.
Honestly, the idea of an 'edit' command used to be appalling to me,
but after three years of using perforce I find that it's not a burden
at all. Not even noticeable. When working on code, the act of
"beginning edits on a file" just doesn't happen that often. It
happens on a handful of files exactly once when you begin the task,
and then that's it. The cost of running 'svn edit' (or C-x,c-q in
emacs) is a drop in the ocean compared to the amount of time spent on
the coding and debugging. It becomes as transparent as all of your
other interaction with the version control system.
RE: svn edit
Posted by "Harvey, Edward" <Ed...@patni.com>.
> At Google,
> our main source tree is gi-normous... we would be *dead* if perforce
> had to walk the tree to tell me which files I had changed. Heck,
> even the Chrome Browser source that Google recently released (in a
> public svn repository) is an unbelievably huge checkout. Same with
> the 6 millions lines of Android code we released in git.
Out of curiosity, can you name something specific, like "chrome has 50,000 files excluding .svn directories" or something like that?
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: svn edit
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> On Tue, Oct 28, 2008 at 11:49 AM, Harvey, Edward
> <Ed...@patni.com> wrote:
>
>
>> Put simply, as far as performance is concerned, Perforce has a strategy that beats the pants off either svn or git. Because perforce doesn't need to walk the tree.
>>
>
> I think this is one of those situations where most open-source users
> (and developers on this project) simply haven't dealt with trees so
> large that tree-walks become a serious hindrance to daily
> productivity. Very few opensource projects are that large. But in
> the corporate world (where both perforce and subversion are intensely
> used) these huge working copies just aren't that unusual. At Google,
> our main source tree is gi-normous... we would be *dead* if perforce
> had to walk the tree to tell me which files I had changed. Heck,
> even the Chrome Browser source that Google recently released (in a
> public svn repository) is an unbelievably huge checkout. Same with
> the 6 millions lines of Android code we released in git.
>
> So while it's not the norm in opensource, I do think that an
> (eventual) implementation of 'svn edit' methodology would make a huge
> impact on the corporate world... perhaps some of Collabnet's clients
> have made comments about this?
>
> Whatever the case, the rewrite of libsvn_wc is what gstein is working
> on now, and is highest priority. This whole 'svn edit' thing is just
> a pie-in-the-sky thing that we'd like to add (as a strictly *optional*
> mode) long after libsvn_wc2 has stabilized. No need to get excited
> about it for now.
>
Of coure comparing svn or git to perforce is like comparing ... roses
and duriang and a bycicle repair shop? The first two are vaguely
related, the third is not -- with the important difference being that
the p4 server knows "everything" about all working copies, or so i'm
told, which implies that p4 edit is also roundtrip to the server ... and
... that the server hardware must be enormous.
Still, the idea that you have to explicitly tell your wc that you're
modifying a file is abominable. I'd much rather spend time on writing a
long-running, stable, etc. etc. inotify daemon with all that implies (or
reasonable facsimile on other systems that support the paradigm).
--Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Tue, Oct 28, 2008 at 4:53 PM, Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> On Tue, Oct 28, 2008 at 10:01 AM, Ben Collins-Sussman
> <su...@red-bean.com> wrote:
>> productivity. Very few opensource projects are that large. But in
>> the corporate world (where both perforce and subversion are intensely
>> used) these huge working copies just aren't that unusual. At Google,
>> our main source tree is gi-normous... we would be *dead* if perforce
>> had to walk the tree to tell me which files I had changed. Heck,
>
> Yah, but the Perforce model gives back all of its speed advantages
> when you try to commit. I remember 30+ minutes trying to submit a
> single file change when using Perforce. (IIRC, Perforce walks all of
> the workspaces at *commit* time.)
Umm, for what it's worth, I suspect your Perforce install was rather
atypical. Most Perforce servers are relatively zippy when submitting
changes.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Oct 28, 2008 at 10:01 AM, Ben Collins-Sussman
<su...@red-bean.com> wrote:
> productivity. Very few opensource projects are that large. But in
> the corporate world (where both perforce and subversion are intensely
> used) these huge working copies just aren't that unusual. At Google,
> our main source tree is gi-normous... we would be *dead* if perforce
> had to walk the tree to tell me which files I had changed. Heck,
Yah, but the Perforce model gives back all of its speed advantages
when you try to commit. I remember 30+ minutes trying to submit a
single file change when using Perforce. (IIRC, Perforce walks all of
the workspaces at *commit* time.)
Ugh. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Tue, Oct 28, 2008 at 11:49 AM, Harvey, Edward
<Ed...@patni.com> wrote:
> Put simply, as far as performance is concerned, Perforce has a strategy that beats the pants off either svn or git. Because perforce doesn't need to walk the tree.
I think this is one of those situations where most open-source users
(and developers on this project) simply haven't dealt with trees so
large that tree-walks become a serious hindrance to daily
productivity. Very few opensource projects are that large. But in
the corporate world (where both perforce and subversion are intensely
used) these huge working copies just aren't that unusual. At Google,
our main source tree is gi-normous... we would be *dead* if perforce
had to walk the tree to tell me which files I had changed. Heck,
even the Chrome Browser source that Google recently released (in a
public svn repository) is an unbelievably huge checkout. Same with
the 6 millions lines of Android code we released in git.
So while it's not the norm in opensource, I do think that an
(eventual) implementation of 'svn edit' methodology would make a huge
impact on the corporate world... perhaps some of Collabnet's clients
have made comments about this?
Whatever the case, the rewrite of libsvn_wc is what gstein is working
on now, and is highest priority. This whole 'svn edit' thing is just
a pie-in-the-sky thing that we'd like to add (as a strictly *optional*
mode) long after libsvn_wc2 has stabilized. No need to get excited
about it for now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn edit
Posted by "Harvey, Edward" <Ed...@patni.com>.
> Harvey, Edward wrote:
> >> Just to illustrate what I mean by "optimizing WC scans"
> and put some
> >> code where my mouth is ... here's a *very* trivial
> example. See the
> >> attached script. On my box, the less_stupid scan is consistenly
> >> 30-40% faster (with full caches!) than the stupid one,
> merely because
> >> it tries to keep accesses slightly more local.
> >>
> >
> > I'm not sure what you mean by "with full caches"
>
> s/full/hot if you prefer
If you have a warm cache, it does not matter how good your performance is, because the performance of all systems on a warm cache is so fast there's no complaint.
The test which matters is cold cache. Cold cache is typical for any environment where the server actually works on and processes files simultaneously while the user is trying to version those files.
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: svn edit
Posted by Branko Čibej <br...@xbc.nu>.
Harvey, Edward wrote:
>> Just to illustrate what I mean by "optimizing WC scans" and put some
>> code where my mouth is ... here's a *very* trivial example. See the
>> attached script. On my box, the less_stupid scan is consistenly 30-40%
>> faster (with full caches!) than the stupid one, merely because it tries
>> to keep accesses slightly more local.
>>
>
> I'm not sure what you mean by "with full caches"
s/full/hot if you prefer
> or "keep access more local"
*That* is the crucial bit. :) Go read the two implementations again, it
should be obvious.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn edit
Posted by "Harvey, Edward" <Ed...@patni.com>.
> Just to illustrate what I mean by "optimizing WC scans" and put some
> code where my mouth is ... here's a *very* trivial example. See the
> attached script. On my box, the less_stupid scan is consistenly 30-40%
> faster (with full caches!) than the stupid one, merely because it tries
> to keep accesses slightly more local.
I'm not sure what you mean by "with full caches" or "keep access more local" but I do know this -
I created a similar python script to walk a tree.
With cold cache, local disk, python walking the tree on 100,000 files takes approx 10 sec
With cold cache, local disk, "svn stat" on 17,000 files (50,000 including .svn dirs) takes approx 4 mins
With cold cache, local disk, "git status" on 17,000 files (30,000 including .git dirs) takes approx 2 mins
Perforce is able to do this is zero time. (a few ms)
Now - If svn is able to get anywhere near the 10 sec mark for 100,000 files, I say fine. But I seriously doubt svn will beat the performance of git by using the same strategy that git uses (walk the tree). This costs at least one order of magnitude in performance.
Put simply, as far as performance is concerned, Perforce has a strategy that beats the pants off either svn or git. Because perforce doesn't need to walk the tree.
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.
RE: svn edit
Posted by "Harvey, Edward" <Ed...@patni.com>.
Incase anybody wants to benchmark anything - on Linux - I learned this from Linus.
echo 3 >/proc/sys/vm/drop_caches
http://marc.info/?l=git&m=122487091128096&w=2
This will make your cache cold, so you can repeat a test with accurate results. (without rebooting)
________________________________________
From: Harvey, Edward
Sent: Tuesday, October 28, 2008 12:49 PM
To: Branko Čibej; dev@subversion.tigris.org
Subject: RE: svn edit
> Just to illustrate what I mean by "optimizing WC scans" and put some
> code where my mouth is ... here's a *very* trivial example. See the
> attached script. On my box, the less_stupid scan is consistenly 30-40%
> faster (with full caches!) than the stupid one, merely because it tries
> to keep accesses slightly more local.
I'm not sure what you mean by "with full caches" or "keep access more local" but I do know this -
I created a similar python script to walk a tree.
With cold cache, local disk, python walking the tree on 100,000 files takes approx 10 sec
With cold cache, local disk, "svn stat" on 17,000 files (50,000 including .svn dirs) takes approx 4 mins
With cold cache, local disk, "git status" on 17,000 files (30,000 including .git dirs) takes approx 2 mins
Perforce is able to do this is zero time. (a few ms)
Now - If svn is able to get anywhere near the 10 sec mark for 100,000 files, I say fine. But I seriously doubt svn will beat the performance of git by using the same strategy that git uses (walk the tree). This costs at least one order of magnitude in performance.
Put simply, as far as performance is concerned, Perforce has a strategy that beats the pants off either svn or git. Because perforce doesn't need to walk the tree.
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: svn edit
Posted by Branko Čibej <br...@xbc.nu>.
Branko Čibej wrote:
> Ben Collins-Sussman wrote:
>
>> Right. Every three months we seem to repeat this thread. :-)
>>
>> X: "How can we make the wc stop crawling huge trees?"
>> Y: "Wc rewrite is happening. There will be less crawling. And we
>> can add 'svn edit' eventually too."
>> X: "How does that work?"
>> Y: "It works like perforce. Thousands of perforce users love it."
>> X: "It sounds awful, I don't want that!"
>> Y: "It's always been planned as *optional* feature, just like changelists are."
>>
>>
>
> IMHO it's unnecessary code bloat. The development time would be better
> spent in optimizing WC scans.
>
Just to illustrate what I mean by "optimizing WC scans" and put some
code where my mouth is ... here's a *very* trivial example. See the
attached script. On my box, the less_stupid scan is consistenly 30-40%
faster (with full caches!) than the stupid one, merely because it tries
to keep accesses slightly more local.
-- Brane
Re: svn edit
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> On Fri, Oct 24, 2008 at 8:17 PM, Listman <li...@burble.net> wrote:
>
>> On Oct 24, 2008, at 4:50 PM- Oct 24, 2008, Blair Zajac wrote:
>>
>>
>>> Ben Collins-Sussman wrote:
>>>
>>>> I have no thread handy, but it's been discussed over and over in the
>>>> wc-ng design as an 'eventual feature' to be implemented. It's
>>>> basically imitating perforce: the entire working copy is read-only.
>>>> When you want to edit a file, you run 'svn edit file', which makes the
>>>> file read-write and registers this fact in sqlite. Then, when you run
>>>> 'svn status', 'svn diff', 'svn commit', etc. there's no need to crawl
>>>> the tree trying to discover local edits; you just ask the database
>>>> which files to stat. It makes things shockingly fast, and while it
>>>> sounds horribly annoying and restrictive to a veteran CVS or SVN user,
>>>> it's actually a really nice way to work.
>>>>
>>> Have we decided that this is something we really want? It does sound very
>>> annoying and restrictive.
>>>
>>> With the speed of the new working coy code, shouldn't we wait to see how
>>> fast that is before even introducing 'svn edit'?
>>>
>>> Are there any other open-source version control systems that use the
>>> read-only model? Isn't the reason 'p4 edit' is needed is to indicate to the
>>> server the intentions to edit the file, which svn doesn't need?
>>>
>>>
>> this going to be optional, if you don't need/want it then you can ignore.
>>
>>
>
> Right. Every three months we seem to repeat this thread. :-)
>
> X: "How can we make the wc stop crawling huge trees?"
> Y: "Wc rewrite is happening. There will be less crawling. And we
> can add 'svn edit' eventually too."
> X: "How does that work?"
> Y: "It works like perforce. Thousands of perforce users love it."
> X: "It sounds awful, I don't want that!"
> Y: "It's always been planned as *optional* feature, just like changelists are."
>
IMHO it's unnecessary code bloat. The development time would be better
spent in optimizing WC scans.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steven Bakke <st...@amd.com>:
> ... Is it so wrong to have an optional mode of operation? (in other
> words, it doesn't need to affect you unless you want it to)
As long as it is an optional client behaviour It doesn't really affect
me, so in that light I don't care (at least: I shouldn't care).
(It's just that I find this behaviour so annoying in perforce, that
responding to suggstions adding it to svn, is almost a conditioned
reflex... sorry about that)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Steven Bakke <st...@amd.com>.
On Oct 26, 2008, at 8:56 AM, Steinar Bang wrote:
>>>>>> "Ben Collins-Sussman" <su...@red-bean.com>:
>
>> Right. Every three months we seem to repeat this thread. :-)
>
>> X: "How can we make the wc stop crawling huge trees?"
>> Y: "Wc rewrite is happening. There will be less crawling. And we
>> can add 'svn edit' eventually too."
>> X: "How does that work?"
>> Y: "It works like perforce. Thousands of perforce users love it."
>> X: "It sounds awful, I don't want that!"
>> Y: "It's always been planned as *optional* feature, just like
>> changelists are."
>
> Right.
>
> But it still sounds awful (and I don't want that (and I can't help
> myself from restating it, when the issue pops up)).
>
> Also I can't believe that thousands of perforce users love it. In
> fact
> I can't even believe that thousands of people loves perforce.
>
Not all users are using version control for mergeable text. Consider
the use-case where users need to operate on binary files which have
needs-lock properties. If adding 'svn edit' will enable a significant
performance improvement over the current situation, I imagine people
would be very happy. There are lots of perforce users that have
exactly that use case. I can understand why you wouldn't want it for
regular mergeable source code. Is it so wrong to have an optional
mode of operation? (in other words, it doesn't need to affect you
unless you want it to)
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Steinar Bang <sb...@dod.no>.
>>>>> "Ben Collins-Sussman" <su...@red-bean.com>:
> Right. Every three months we seem to repeat this thread. :-)
> X: "How can we make the wc stop crawling huge trees?"
> Y: "Wc rewrite is happening. There will be less crawling. And we
> can add 'svn edit' eventually too."
> X: "How does that work?"
> Y: "It works like perforce. Thousands of perforce users love it."
> X: "It sounds awful, I don't want that!"
> Y: "It's always been planned as *optional* feature, just like changelists are."
Right.
But it still sounds awful (and I don't want that (and I can't help
myself from restating it, when the issue pops up)).
Also I can't believe that thousands of perforce users love it. In fact
I can't even believe that thousands of people loves perforce.
Oh well.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Fri, Oct 24, 2008 at 8:17 PM, Listman <li...@burble.net> wrote:
>
> On Oct 24, 2008, at 4:50 PM- Oct 24, 2008, Blair Zajac wrote:
>
>> Ben Collins-Sussman wrote:
>>>
>>> I have no thread handy, but it's been discussed over and over in the
>>> wc-ng design as an 'eventual feature' to be implemented. It's
>>> basically imitating perforce: the entire working copy is read-only.
>>> When you want to edit a file, you run 'svn edit file', which makes the
>>> file read-write and registers this fact in sqlite. Then, when you run
>>> 'svn status', 'svn diff', 'svn commit', etc. there's no need to crawl
>>> the tree trying to discover local edits; you just ask the database
>>> which files to stat. It makes things shockingly fast, and while it
>>> sounds horribly annoying and restrictive to a veteran CVS or SVN user,
>>> it's actually a really nice way to work.
>>
>> Have we decided that this is something we really want? It does sound very
>> annoying and restrictive.
>>
>> With the speed of the new working coy code, shouldn't we wait to see how
>> fast that is before even introducing 'svn edit'?
>>
>> Are there any other open-source version control systems that use the
>> read-only model? Isn't the reason 'p4 edit' is needed is to indicate to the
>> server the intentions to edit the file, which svn doesn't need?
>>
>
> this going to be optional, if you don't need/want it then you can ignore.
>
Right. Every three months we seem to repeat this thread. :-)
X: "How can we make the wc stop crawling huge trees?"
Y: "Wc rewrite is happening. There will be less crawling. And we
can add 'svn edit' eventually too."
X: "How does that work?"
Y: "It works like perforce. Thousands of perforce users love it."
X: "It sounds awful, I don't want that!"
Y: "It's always been planned as *optional* feature, just like changelists are."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Listman <li...@burble.net>.
On Oct 24, 2008, at 4:50 PM- Oct 24, 2008, Blair Zajac wrote:
> Ben Collins-Sussman wrote:
>> I have no thread handy, but it's been discussed over and over in the
>> wc-ng design as an 'eventual feature' to be implemented. It's
>> basically imitating perforce: the entire working copy is read-only.
>> When you want to edit a file, you run 'svn edit file', which makes
>> the
>> file read-write and registers this fact in sqlite. Then, when you
>> run
>> 'svn status', 'svn diff', 'svn commit', etc. there's no need to crawl
>> the tree trying to discover local edits; you just ask the database
>> which files to stat. It makes things shockingly fast, and while it
>> sounds horribly annoying and restrictive to a veteran CVS or SVN
>> user,
>> it's actually a really nice way to work.
>
> Have we decided that this is something we really want? It does
> sound very annoying and restrictive.
>
> With the speed of the new working coy code, shouldn't we wait to see
> how fast that is before even introducing 'svn edit'?
>
> Are there any other open-source version control systems that use the
> read-only model? Isn't the reason 'p4 edit' is needed is to
> indicate to the server the intentions to edit the file, which svn
> doesn't need?
>
this going to be optional, if you don't need/want it then you can
ignore.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn edit
Posted by Blair Zajac <bl...@orcaware.com>.
Ben Collins-Sussman wrote:
> I have no thread handy, but it's been discussed over and over in the
> wc-ng design as an 'eventual feature' to be implemented. It's
> basically imitating perforce: the entire working copy is read-only.
> When you want to edit a file, you run 'svn edit file', which makes the
> file read-write and registers this fact in sqlite. Then, when you run
> 'svn status', 'svn diff', 'svn commit', etc. there's no need to crawl
> the tree trying to discover local edits; you just ask the database
> which files to stat. It makes things shockingly fast, and while it
> sounds horribly annoying and restrictive to a veteran CVS or SVN user,
> it's actually a really nice way to work.
Have we decided that this is something we really want? It does sound very
annoying and restrictive.
With the speed of the new working coy code, shouldn't we wait to see how fast
that is before even introducing 'svn edit'?
Are there any other open-source version control systems that use the read-only
model? Isn't the reason 'p4 edit' is needed is to indicate to the server the
intentions to edit the file, which svn doesn't need?
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn edit
Posted by "Harvey, Edward" <Ed...@patni.com>.
> BTW, I recently found out that there is an `svn status -q' which omits
> unversioned items. If that's of any relevance.
Forgive the cross-posting, but I felt this deserves a comment in this thread too.
Does "svn status -q" omit anything besides unversioned items?
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: svn edit
Posted by "Neels J. Hofmeyr" <ne...@elego.de>.
Harvey, Edward wrote:
>> This seems needlessly complex, and forces *everyone* on the project to
>
>> either use the 'svn edit' feature or not. It's much more elegant to
>
>> make the feature a mode that each user can choose for themselves:
>
>> probably an option to 'svn checkout' which activates this "everything
>
>> is read-only" mode.
>
>
>> You're right that the existing "needs-lock" property sort of reflects
>
>> the behavior we want, but in that case we really *do* want to dictate
>
>> that absolutely every project member play along, since there's a real
>
>> risk of wasted time when people aren't taking strict turns editing a
>
>> binary file. When it comes to a hypothetical 'svn edit' feature,
>
>> though, nobody should need to know whether I'm choosing to work that
>
>> way or not; it should be a private run-time behavior I choose for
>
>> myself.
>
>
>
> I agree with your correction, the "svn edit" should be a local thing, not
> something that gets forced onto all users regardless of whether or not
> they like it. Additionally, I found a flaw in my previous thinking. The
> need to walk the tree is not just to inspect the versioned files. "svn
> status" presently will give you information about unversioned files too.
BTW, I recently found out that there is an `svn status -q' which omits
unversioned items. If that's of any relevance.
>
>
>
> In order to avoid walking the tree, you need to assume:
>
> 1. None of the versioned files have been locally modified, except those
> which have already been identified.
>
> 2. All of the unversioned files (if any) are safe to ignore. The user
> doesn't want to "svn add" them.
>
>
>
> To achieve these assumptions safely, I can see two possible solutions:
>
>
>
> Common for both scenarios
>
> 1. Let directories in the WC have the ability to take an
> "ignore-unversioned" flag.
>
> 2. Inside of directories which have this flag, "svn status" (and
> others?) will ignore all unversioned files and directories.
>
> 3. It seems possible to let "ignore-unversioned" be implemented as a
> property inside the repository, or inside the WC, or both. If it's
> inside the repo, it has the advantage that it can be automatically
> distributed to all the clients, in organizations that have a standard
> mode of operations for development. If it's inside the WC, it has the
> advantage that users can set or unset it without affecting anyone else.
> The most flexible solution is to implement in both places - Let it be
> distributed by the repository, and also let it be overridden in the local
> WC - but this is also the most work to build. The question of
> implementation - to implement "ignore-unversioned" in WC or in Repo or in
> both - I leave to whoever. All three ways are adequate solutions.
>
> 4. It would probably be worthwhile to implement a new switch "svn status
> --scan-for-unversioned" for the situation in which a user wants to scan
> anyway.
See above, `svn status -q' vs. `svn status'.
~Neels
>
>
>
> Scenario 1 - Performance Motivated Locking
>
> 1. At present, I believe "needs-lock" can only be applied to files, not
> directories. Right? Even if you use auto-props on a directory, it's
> still just giving the property to all the individual files.
>
> 2. Let directories inside the repository have the ability to take a
> needs-lock property. If a directory has this property, then all its
> children inherit it too.
>
> 3. As a result, "svn status" (and other commands?) can safely assume
> that no files are modified in the directory or any of its subdirs, except
> files which were previously locked. No need to scan for modified files.
>
>
> 4. It would probably be worthwhile to implement a new switch "svn status
> --scan-for-modified" for the situation in which a user wants to scan
> anyway.
>
> 5. If a directory has both "needs-lock" and "ignore-unversioned" then
> "svn status" (and other commands?) can avoid the need to walk the tree.
>
>
>
> Scenario 2 - Performance Motivated Editing
>
> 1. Let directories in the WC have the ability to take a "needs-edit"
> flag.
>
> 2. Inside of directories which have this flag, "svn status" (and
> others?) will assume that none of your versioned files are modified,
> unless the user previously did "svn edit" on the file.
>
> 3. If the user does "svn lock" on a file, it probably implies "svn edit"
> right? And "svn unlock" implies "svn unedit"?
>
> 4. It again seems possible to implement "needs-edit" in either the WC,
> the repository, or both. There are advantages to each way. The most
> flexible solution is to implement in both locations, which also requires
> the most work. All three possibilities are good solutions.
>
> 5. Again, it seems like it would do no harm to implement "svn status
> --scan-for-modified" for the situation in which a user wants to scan
> anyway. And perhaps "svn status --scan" which is synonymous with
> "--scan-for-unversioned --scan-for-modified"
>
> 6. If a directory has both "needs-edit" and "ignore-unversioned" then
> "svn status" (and other commands?) can avoid the need to walk the tree.
>
> ________________________________ 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.
>
RE: svn edit
Posted by "Harvey, Edward" <Ed...@patni.com>.
> This seems needlessly complex, and forces *everyone* on the project to
> either use the 'svn edit' feature or not. It's much more elegant to
> make the feature a mode that each user can choose for themselves:
> probably an option to 'svn checkout' which activates this "everything
> is read-only" mode.
>
> You're right that the existing "needs-lock" property sort of reflects
> the behavior we want, but in that case we really *do* want to dictate
> that absolutely every project member play along, since there's a real
> risk of wasted time when people aren't taking strict turns editing a
> binary file. When it comes to a hypothetical 'svn edit' feature,
> though, nobody should need to know whether I'm choosing to work that
> way or not; it should be a private run-time behavior I choose for
> myself.
I agree with your correction, the "svn edit" should be a local thing, not something that gets forced onto all users regardless of whether or not they like it. Additionally, I found a flaw in my previous thinking. The need to walk the tree is not just to inspect the versioned files. "svn status" presently will give you information about unversioned files too.
In order to avoid walking the tree, you need to assume:
1. None of the versioned files have been locally modified, except those which have already been identified.
2. All of the unversioned files (if any) are safe to ignore. The user doesn't want to "svn add" them.
To achieve these assumptions safely, I can see two possible solutions:
Common for both scenarios
1. Let directories in the WC have the ability to take an "ignore-unversioned" flag.
2. Inside of directories which have this flag, "svn status" (and others?) will ignore all unversioned files and directories.
3. It seems possible to let "ignore-unversioned" be implemented as a property inside the repository, or inside the WC, or both. If it's inside the repo, it has the advantage that it can be automatically distributed to all the clients, in organizations that have a standard mode of operations for development. If it's inside the WC, it has the advantage that users can set or unset it without affecting anyone else. The most flexible solution is to implement in both places - Let it be distributed by the repository, and also let it be overridden in the local WC - but this is also the most work to build. The question of implementation - to implement "ignore-unversioned" in WC or in Repo or in both - I leave to whoever. All three ways are adequate solutions.
4. It would probably be worthwhile to implement a new switch "svn status --scan-for-unversioned" for the situation in which a user wants to scan anyway.
Scenario 1 - Performance Motivated Locking
1. At present, I believe "needs-lock" can only be applied to files, not directories. Right? Even if you use auto-props on a directory, it's still just giving the property to all the individual files.
2. Let directories inside the repository have the ability to take a needs-lock property. If a directory has this property, then all its children inherit it too.
3. As a result, "svn status" (and other commands?) can safely assume that no files are modified in the directory or any of its subdirs, except files which were previously locked. No need to scan for modified files.
4. It would probably be worthwhile to implement a new switch "svn status --scan-for-modified" for the situation in which a user wants to scan anyway.
5. If a directory has both "needs-lock" and "ignore-unversioned" then "svn status" (and other commands?) can avoid the need to walk the tree.
Scenario 2 - Performance Motivated Editing
1. Let directories in the WC have the ability to take a "needs-edit" flag.
2. Inside of directories which have this flag, "svn status" (and others?) will assume that none of your versioned files are modified, unless the user previously did "svn edit" on the file.
3. If the user does "svn lock" on a file, it probably implies "svn edit" right? And "svn unlock" implies "svn unedit"?
4. It again seems possible to implement "needs-edit" in either the WC, the repository, or both. There are advantages to each way. The most flexible solution is to implement in both locations, which also requires the most work. All three possibilities are good solutions.
5. Again, it seems like it would do no harm to implement "svn status --scan-for-modified" for the situation in which a user wants to scan anyway. And perhaps "svn status --scan" which is synonymous with "--scan-for-unversioned --scan-for-modified"
6. If a directory has both "needs-edit" and "ignore-unversioned" then "svn status" (and other commands?) can avoid the need to walk the tree.
________________________________
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.
Re: svn edit
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Fri, Oct 24, 2008 at 9:30 PM, Harvey, Edward <Ed...@patni.com> wrote:
> The fundamental difference between perforce's locking scheme, versus svn's
> merging scheme is mergability. Multiple svn users want to simultaneously
> edit the same files and allow the merge to take place whenever possible.
Huh? I've been using p4 for 3 years now, and I've *never* seen anyone
use it in lock-modify-lock mode (a la Visual Sourcesafe). It uses the
same copy-modify-merge model as CVS and SVN. At least, that's all
I've ever seen. That's why it has fantastic interactive conflict
resolution, and why we imitated it. :-)
> 3. Let there also be a "needs-edit" property, which behaves similarly to
> the needs-lock property: The file is read-only until "svn edit." Then the
> file is read-write, but there is no repository lock. "svn status" will
> assume a file is not locally modified if it has the needs-edit property and
> hasn't been "svn edit"ed
This seems needlessly complex, and forces *everyone* on the project to
either use the 'svn edit' feature or not. It's much more elegant to
make the feature a mode that each user can choose for themselves:
probably an option to 'svn checkout' which activates this "everything
is read-only" mode.
You're right that the existing "needs-lock" property sort of reflects
the behavior we want, but in that case we really *do* want to dictate
that absolutely every project member play along, since there's a real
risk of wasted time when people aren't taking strict turns editing a
binary file. When it comes to a hypothetical 'svn edit' feature,
though, nobody should need to know whether I'm choosing to work that
way or not; it should be a private run-time behavior I choose for
myself.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn edit
Posted by "Harvey, Edward" <Ed...@patni.com>.
Rather than push the direction of "let's be more like perforce," instead let's understand the fundamental concept that makes perforce lightning fast for things like "p4 status" and then apply the knowledge to svn in a svn-ish way.
In perforce, it is implied that all files need lock before they can be edited. Until you use "p4 edit" the file is read-only. "p4 edit" will get a repository lock and make your local copy read-write. Therefore "p4 status" can assume you didn't modify any file other than the ones that you "p4 edit"ed. Therefore "p4 status" is a near-zero cost operation. It just displays to you the list of files that you said you would edit.
The fundamental difference between perforce's locking scheme, versus svn's merging scheme is mergability. Multiple svn users want to simultaneously edit the same files and allow the merge to take place whenever possible. Here's what I suggest:
1. Given: files that have the "needs-lock" property are read-only until you "svn lock" them, after which they are read-write, and locked in the repository. (Just like perforce.)
2. Let "svn status" assume that a file is not locally modified, if it has needs-lock property and hasn't been locked.
Given #1 and #2, we're able to match the performance of perforce. It's pretty cool for free software to beat expensive software at their own game, but it's not very subversion-ish to set needs-lock on all files. We can do even better...
3. Let there also be a "needs-edit" property, which behaves similarly to the needs-lock property: The file is read-only until "svn edit." Then the file is read-write, but there is no repository lock. "svn status" will assume a file is not locally modified if it has the needs-edit property and hasn't been "svn edit"ed
4. (For this last point, I think there is already has a solution, yes?) Let both the needs-lock and needs-edit properties have a simple way to assign them globally, to get set automatically on all new files. So the administrator can deploy a needs-lock or needs-edit policy.
Strangely, what I've described above is analogous to filesystem journaling. You perform many small-cost maintenance operations as you go along, so you never incur the large-cost scan. Imagine if you had inotify/FSEvents/FindFirstChangeNotification/etc available to call "svn edit" on every file automatically for you when you "vi" the file. Then the system would be transparently maintaining a list of files that you edited, and you'd never take the performance hit of scanning the tree, and you'd never consider it inconvenient to type "svn edit" because it happens automatically for you.
Whoever commented on my signature - please ignore it. It's tagged on by company policy, and I cannot change it.
________________________________
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.
Re: svn edit
Posted by Ben Collins-Sussman <su...@red-bean.com>.
I have no thread handy, but it's been discussed over and over in the
wc-ng design as an 'eventual feature' to be implemented. It's
basically imitating perforce: the entire working copy is read-only.
When you want to edit a file, you run 'svn edit file', which makes the
file read-write and registers this fact in sqlite. Then, when you run
'svn status', 'svn diff', 'svn commit', etc. there's no need to crawl
the tree trying to discover local edits; you just ask the database
which files to stat. It makes things shockingly fast, and while it
sounds horribly annoying and restrictive to a veteran CVS or SVN user,
it's actually a really nice way to work.
On Fri, Oct 24, 2008 at 4:28 PM, Neels J Hofmeyr <ne...@elego.de> wrote:
>
>
> Ben Collins-Sussman wrote:
>> Or, just wait for the working-copy rewrite (in progress now) to
>> implement an 'svn edit' command. No more crawling the working copy at
>> all.
>
> Say, what?
> Got a pointer for me that explains it?
>
> Thanks
> ~Neels
>
> --
> Neels Hofmeyr -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23458696 mobile: +49 177 2345869 fax: +49 30 23458695
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org