You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Garrett Rooney <ro...@electricjellyfish.net> on 2003/07/31 13:44:58 UTC
A real world user's impression of Subversion
So I've been reading the Ponie (the project to port perl5 to the parrot
VM) mailing lists, since they're trying out Subversion, and it seems
that they've not had the best time with it so far.
So far the primary problem seems to be speed. It's just too slow when
working with large projects. Anyway, you can read Arthur's mail for the
details of his complaints, but I just thought you guys might be
interested in seeing what some competent developers think now that
they've given us a chance.
I mean it isn't like these guys are clueless newbies who haven't been
able to figure out the tool, the've got some serious issues, and try as
I might, I can't blame them for being upset.
-garrett
Re: A real world user's impression of Subversion
Posted by Blair Zajac <bl...@orcaware.com>.
cmpilato@collab.net wrote:
>
> Blair Zajac <bl...@orcaware.com> writes:
>
> > Well, I vote to support it since I wrote it, but I guess that means
> > I'll have to put some more energy into it :) which I can make time for
> > :)
>
> Well, we can always give it its own repository and you can support it
> all day long. :-)
I don't get what you mean here. Is this an attempt at humor :)
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by cm...@collab.net.
Blair Zajac <bl...@orcaware.com> writes:
> Well, I vote to support it since I wrote it, but I guess that means
> I'll have to put some more energy into it :) which I can make time for
> :)
Well, we can always give it its own repository and you can support it
all day long. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Blair Zajac <bl...@orcaware.com>.
Garrett Rooney wrote:
>
> kfogel@collab.net wrote:
>
> > The svn_load_dirs problem is unfortunate, but on the other hand, we
> > don't really consider the stuff in tools/ to be part of the core
> > product (at least as far as developer group endorsement goes!). It's
> > contributed stuff that we include in our distribution solely to make
> > things more convenient. Perhaps we need to make this clearer, though?
> >
> > (It's also possible that svn_load_dirs is slow because of some
> > underlying problem in Subversion. If so, it would be nice to get some
> > demonstration of that. I don't know svn_load_dirs's algorithm, so
> > can't say off the top of my head.)
>
> With regard to svn_load_dirs.pl, if we're not going to support it, we
> shouldn't be mentioning it in the book. That said, there is a TODO
> somewhere to rewrite the section of the book on vendor branches, and I
> think Mike said something about just not mentioning svn_load_dirs.pl at all.
Well, I vote to support it since I wrote it, but I guess that means
I'll have to put some more energy into it :) which I can make time for
:)
I think the script can be made more efficient, or at least take some
additional command line options to skip consistency checks that will
speed up the script.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
kfogel@collab.net wrote:
> The svn_load_dirs problem is unfortunate, but on the other hand, we
> don't really consider the stuff in tools/ to be part of the core
> product (at least as far as developer group endorsement goes!). It's
> contributed stuff that we include in our distribution solely to make
> things more convenient. Perhaps we need to make this clearer, though?
>
> (It's also possible that svn_load_dirs is slow because of some
> underlying problem in Subversion. If so, it would be nice to get some
> demonstration of that. I don't know svn_load_dirs's algorithm, so
> can't say off the top of my head.)
With regard to svn_load_dirs.pl, if we're not going to support it, we
shouldn't be mentioning it in the book. That said, there is a TODO
somewhere to rewrite the section of the book on vendor branches, and I
think Mike said something about just not mentioning svn_load_dirs.pl at all.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by "Jamin W. Collins" <jc...@asgardsrealm.net>.
On Thu, Jul 31, 2003 at 01:10:41PM -0500, cmpilato@collab.net wrote:
> "Jamin W. Collins" <jc...@asgardsrealm.net> writes:
>
> > No, a good deal of the reason svn_load_dirs is slow is detailed here:
> >
> > http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=259005
>
> And did you embrace the opportunity to submit a patch? :-)
Not yet, I don't know perl very well at all. I'm still interested in
doing so, but sadly lack the familiarity with perl.
--
Jamin W. Collins
Remember, root always has a loaded gun. Don't run around with it unless
you absolutely need it. -- Vineet Kumar
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by cm...@collab.net.
"Jamin W. Collins" <jc...@asgardsrealm.net> writes:
> No, a good deal of the reason svn_load_dirs is slow is detailed here:
>
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=259005
And did you embrace the opportunity to submit a patch? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by "Jamin W. Collins" <jc...@asgardsrealm.net>.
On Thu, Jul 31, 2003 at 11:20:16AM -0500, kfogel@collab.net wrote:
> The svn_load_dirs problem is unfortunate, but on the other hand, we
> don't really consider the stuff in tools/ to be part of the core
> product (at least as far as developer group endorsement goes!). It's
> contributed stuff that we include in our distribution solely to make
> things more convenient. Perhaps we need to make this clearer, though?
>
> (It's also possible that svn_load_dirs is slow because of some
> underlying problem in Subversion. If so, it would be nice to get some
> demonstration of that. I don't know svn_load_dirs's algorithm, so
> can't say off the top of my head.)
No, a good deal of the reason svn_load_dirs is slow is detailed here:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=259005
--
Jamin W. Collins
This is the typical unix way of doing things: you string together lots
of very specific tools to accomplish larger tasks. -- Vineet Kumar
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Oliver Geisser <ol...@gmx.de>.
Hi.
kfogel@collab.net wrote:
[...]
> The svn_load_dirs problem is unfortunate, but on the other hand, we
> don't really consider the stuff in tools/ to be part of the core
> product (at least as far as developer group endorsement goes!). It's
> contributed stuff that we include in our distribution solely to make
> things more convenient. Perhaps we need to make this clearer, though?
[...]
Ups. To make clear that I understand this correctly:
The tool "svn_load_dirs" is not an official part of subversion?
If this is true what is the recommended way (best practice) to
manage vendor branches (without "svn_load_dirs") ?
How about making "svn_load_dirs" part of the core development?
Ciao, Olli
--og
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by kf...@collab.net.
David Summers <da...@summersoft.fay.ar.us> writes:
> Maybe most or many of the stuff in "tools" could be renamed to "contrib"
> if it is not officially supported by the project? Only the officially
> supported stuff could be put/left in "tools".
>
> That would make it crystal clear in my mind what is supported and what is
> not.
>
> Please don't put "cvs2svn" in "contrib"! :-)
I think that would be a good distinction; I (or someone) would need to
spend some time categorizing. Can you come up with a categorization
and post? That would be great...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by cm...@collab.net.
David Summers <da...@summersoft.fay.ar.us> writes:
> On 31 Jul 2003 kfogel@collab.net wrote:
> > The svn_load_dirs problem is unfortunate, but on the other hand, we
> > don't really consider the stuff in tools/ to be part of the core
> > product (at least as far as developer group endorsement goes!). It's
> > contributed stuff that we include in our distribution solely to make
> > things more convenient. Perhaps we need to make this clearer, though?
>
> Maybe most or many of the stuff in "tools" could be renamed to "contrib"
> if it is not officially supported by the project? Only the officially
> supported stuff could be put/left in "tools".
Ooh! +1.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by kf...@collab.net.
David Summers <da...@summersoft.fay.ar.us> writes:
> I would be glad to tackle the re-arranging job if people are interested.
> I could produce a list of items to move in to contrib from tools and
> present to the dev list and then given the OK, go ahead and move them in
> my working copy, build an RPM and make sure the build still works, and
> then commit it.
>
> Let me know if people are interested in having this done.
Heh. I should have read all the thread first.
+1, and thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: A real world user's impression of Subversion
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Thu, 31 Jul 2003, Sander Striker wrote:
> > On 31 Jul 2003 kfogel@collab.net wrote:
> > > The svn_load_dirs problem is unfortunate, but on the other hand, we
> > > don't really consider the stuff in tools/ to be part of the core
> > > product (at least as far as developer group endorsement goes!). It's
> > > contributed stuff that we include in our distribution solely to make
> > > things more convenient. Perhaps we need to make this clearer, though?
> >
> > Maybe most or many of the stuff in "tools" could be renamed to "contrib"
> > if it is not officially supported by the project? Only the officially
> > supported stuff could be put/left in "tools".
> >
> > That would make it crystal clear in my mind what is supported and what is
> > not.
>
> +1.
>
> > Please don't put "cvs2svn" in "contrib"! :-)
>
> Nor mailer.py, nor ...
>
I would be glad to tackle the re-arranging job if people are interested.
I could produce a list of items to move in to contrib from tools and
present to the dev list and then given the OK, go ahead and move them in
my working copy, build an RPM and make sure the build still works, and
then commit it.
Let me know if people are interested in having this done.
Thanks!
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: A real world user's impression of Subversion
Posted by Sander Striker <st...@apache.org>.
> From: David Summers [mailto:david@summersoft.fay.ar.us]
> Sent: Thursday, July 31, 2003 6:56 PM
> On 31 Jul 2003 kfogel@collab.net wrote:
> > The svn_load_dirs problem is unfortunate, but on the other hand, we
> > don't really consider the stuff in tools/ to be part of the core
> > product (at least as far as developer group endorsement goes!). It's
> > contributed stuff that we include in our distribution solely to make
> > things more convenient. Perhaps we need to make this clearer, though?
>
> Maybe most or many of the stuff in "tools" could be renamed to "contrib"
> if it is not officially supported by the project? Only the officially
> supported stuff could be put/left in "tools".
>
> That would make it crystal clear in my mind what is supported and what is
> not.
+1.
> Please don't put "cvs2svn" in "contrib"! :-)
Nor mailer.py, nor ...
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by David Summers <da...@summersoft.fay.ar.us>.
On 31 Jul 2003 kfogel@collab.net wrote:
> The svn_load_dirs problem is unfortunate, but on the other hand, we
> don't really consider the stuff in tools/ to be part of the core
> product (at least as far as developer group endorsement goes!). It's
> contributed stuff that we include in our distribution solely to make
> things more convenient. Perhaps we need to make this clearer, though?
Maybe most or many of the stuff in "tools" could be renamed to "contrib"
if it is not officially supported by the project? Only the officially
supported stuff could be put/left in "tools".
That would make it crystal clear in my mind what is supported and what is
not.
Please don't put "cvs2svn" in "contrib"! :-)
--
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Arthur Bergman <ar...@fotango.com>.
On Thursday, July 31, 2003, at 05:20 pm, kfogel@collab.net wrote:
>
> The svn_load_dirs problem is unfortunate, but on the other hand, we
> don't really consider the stuff in tools/ to be part of the core
> product (at least as far as developer group endorsement goes!). It's
> contributed stuff that we include in our distribution solely to make
> things more convenient. Perhaps we need to make this clearer, though?
>
> (It's also possible that svn_load_dirs is slow because of some
> underlying problem in Subversion. If so, it would be nice to get some
> demonstration of that. I don't know svn_load_dirs's algorithm, so
> can't say off the top of my head.)
>
>
I think part of svn_load_dirs slowness is just that is checkouts the
vendor branch in question.
The subversion book recommend svn_load_dirs, and infact doing vendor
imports manually is a painful operation (and in Ponie this is important
since I am tracking vendor changes from both Parrot and Perl). There
must be a supported way of doing vendor branches and vendor merging.
I also should say that I have been running subversion for a 9 months
and been very happy with it, but sadly it has failed to work with Ponie.
Arthur
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by kf...@collab.net.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> So far the primary problem seems to be speed. It's just too slow when
> working with large projects. Anyway, you can read Arthur's mail for
> the details of his complaints, but I just thought you guys might be
> interested in seeing what some competent developers think now that
> they've given us a chance.
[I've CC'd Arthur, hope he doesn't mind.]
Yup, sounds like Arthur encountered some known performance issues.
Which isn't surprising; they're exactly what we're concentrating on
right now, because they have such a big impact on users.
The checkout speed issue is already filed as:
http://subversion.tigris.org/issues/show_bug.cgi?id=1429
The commit speed issue (taking 1m22s to commit two files) might be:
http://subversion.tigris.org/issues/show_bug.cgi?id=1452
...unless the deltas involved were huge, in which case 1m22s is
perfectly reasonable. From Arthur's tone, though, I'm guessing that
the delta was not that huge :-). (But it's hard to be sure it's issue
#1452 without more information, obviously.)
The svn_load_dirs problem is unfortunate, but on the other hand, we
don't really consider the stuff in tools/ to be part of the core
product (at least as far as developer group endorsement goes!). It's
contributed stuff that we include in our distribution solely to make
things more convenient. Perhaps we need to make this clearer, though?
(It's also possible that svn_load_dirs is slow because of some
underlying problem in Subversion. If so, it would be nice to get some
demonstration of that. I don't know svn_load_dirs's algorithm, so
can't say off the top of my head.)
> I mean it isn't like these guys are clueless newbies who haven't been
> able to figure out the tool, the've got some serious issues, and try
> as I might, I can't blame them for being upset.
Nope, I can't blame him either.
Arthur, you should probably just try again in a few months, or watch
those specific issues. If you can help verify that your commit
slowness is indeed issue #1452, that would be great, but will
understand if you're too busy.
Hope to see you again -- and happier next time.
-Karl
> From: Arthur Bergman <ar...@fotango.com>
> Subject: Subversion
> To: ponie-dev@perl.org
> Date: Thu, 31 Jul 2003 14:36:29 +0100
>
> Hi,
>
> I think I can conclude my attempt to use subversion as
> ____ __ __ _ _ ____ _ _ ____ _ __ ____
> / ___| \ \ / / | \ | | / ___| | | | | / ___| | |/ / / ___|
> \___ \ \ \ / / | \| | \___ \ | | | | | | | ' / \___ \
> ___) | \ V / | |\ | ___) | | |_| | | |___ | . \ ___) |
> |____/ \_/ |_| \_| |____/ \___/ \____| |_|\_\ |____/
>
> (SUBVERSION SUCKS)
>
> First of all, checking out parrot using subversion takes at least 4
> time slonger than CVS
>
> Doing a vendor checkin brining up parrot to latest version is a major
> pain the arse. The process alone of running svn_load_dirs takes around
> an hour, and then I have to tag it (because if you tell svn_load_dirs
> to tag things automatically it breaks). It also seems not to have
> changed some stuff when other stuff has changed!
> (http://svn.perl.org/ponie/vendor/parrot/current/config/auto/gcc.pl is
> one file that should have been updated).
>
> Committing two files took 1 minute 22 second yesterday, a checkout is
> extremely painfully slow. I am very close to saying it is a failed
> experiment and either go to p4 or cvs for the time being.
>
> A very angry Arthur who has spent far too much time battling an
> substandard versioning system. (which might be theoretically very
> nice, but does not scale)
>
>
> ps. And off I go to try and do another merge of parrot!
> ----------
>
> ---------------------------------------------------------------------
> 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: A real world user's impression of Subversion
Posted by Ben Collins-Sussman <su...@collab.net>.
Zack Brown <zb...@tumblerings.org> writes:
> On Thu, Jul 31, 2003 at 09:44:58AM -0400, Garrett Rooney wrote:
> > So far the primary problem seems to be speed. It's just too slow when
> > working with large projects.
>
> On Thu, 31 Jul 2003 14:36:29 +0100, Arthur Bergman wrote:
> > checking out parrot using subversion takes at least 4
> > time slonger than CVS
>
> This is incredible! Only 4 times slower than CVS, and *that's* the
> biggest objection!
>
> That's really great news. When I think of the situation 2 or 3 years ago,
> I have to laugh that posts like the above are flames and not praise. It
> looks like Subversion is well on the way to world domination. Kudos to
> the developers!
Performance and scalability issues have been filed, and will be fixed,
I'm sure of it. We already have an issue (thanks to plasmabal)
specifically about how unbelievably slow 'checkout' is.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Zack Brown <zb...@tumblerings.org>.
On Thu, Jul 31, 2003 at 09:44:58AM -0400, Garrett Rooney wrote:
> So far the primary problem seems to be speed. It's just too slow when
> working with large projects.
On Thu, 31 Jul 2003 14:36:29 +0100, Arthur Bergman wrote:
> checking out parrot using subversion takes at least 4
> time slonger than CVS
This is incredible! Only 4 times slower than CVS, and *that's* the
biggest objection!
That's really great news. When I think of the situation 2 or 3 years ago,
I have to laugh that posts like the above are flames and not praise. It
looks like Subversion is well on the way to world domination. Kudos to
the developers!
Be well,
Zack
--
Zack Brown
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Robert Spier <rs...@pobox.com>.
> > Apparently this is an Apache 2.0 authz issue. I'm considering moving
> > authz access to https, and leaving http being read only anon access,
> > but I'm slightly worried about concurrent access.
>
> Why would you be concerned about concurrent access?
> BDB (if it is working properly) should ensure that there isn't problems with
> concurrent modifications or access. -- justin
Because sometimes it's very hard to tell if BDB actually is working
properly, until it's too late.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, July 31, 2003 1:22 PM -0700 Robert Spier <rs...@pobox.com>
wrote:
> Apparently this is an Apache 2.0 authz issue. I'm considering moving
> authz access to https, and leaving http being read only anon access,
> but I'm slightly worried about concurrent access.
Why would you be concerned about concurrent access?
BDB (if it is working properly) should ensure that there isn't problems with
concurrent modifications or access. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Robert Spier <rs...@pobox.com>.
> > If I do but it checks out http://sky@svn.perl.org/ponie/vendor/parro
> > which is huge
>
> Hmm, password protected site. It would be handy to have anonymous
> users with read-only access.
Apparently this is an Apache 2.0 authz issue. I'm considering moving
authz access to https, and leaving http being read only anon access,
but I'm slightly worried about concurrent access.
You can use 'anon' with no password and it should let you in.
-R
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Blair Zajac <bl...@orcaware.com>.
Branko ?ibej wrote:
>
> Blair Zajac wrote:
>
> >Blair Zajac wrote:
> >
> >
> >>Arthur Bergman wrote:
> >>
> >>
> >>>Yes, but I need to tag the imports, becomes kind of hard to the merge
> >>>otherwise? Why does svn_load_dirs need to checkout all the tags?
> >>>
> >>>
> >>It doesn't need to check out everything. I'll make a change that
> >>only checks out the specified directory being imported and the one
> >>directory that was tagged to run a consistency check.
> >>
> >>
> >
> >Turns out there is a reason to check out the top level URL supplied
> >to svn_load_dirs. It checks out the top level directory so the
> >script can then check if any directories given to svn_load_dirs on
> >the command line need to be created.
> >
> Wouldn't "svn ls -v URL" be a better choice here? There's no need to do
> a checkout if you just want to see if a particular directory exists. If
> that's not enough, "svn co -N URL" would work these days, too.
The latest version of the script runs "svn log -r HEAD" on the directory
in question. It could probably be made smarter, but this isn't the
slow part of the import process.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Branko Čibej <br...@xbc.nu>.
Blair Zajac wrote:
>Blair Zajac wrote:
>
>
>>Arthur Bergman wrote:
>>
>>
>>>Yes, but I need to tag the imports, becomes kind of hard to the merge
>>>otherwise? Why does svn_load_dirs need to checkout all the tags?
>>>
>>>
>>It doesn't need to check out everything. I'll make a change that
>>only checks out the specified directory being imported and the one
>>directory that was tagged to run a consistency check.
>>
>>
>
>Turns out there is a reason to check out the top level URL supplied
>to svn_load_dirs. It checks out the top level directory so the
>script can then check if any directories given to svn_load_dirs on
>the command line need to be created.
>
Wouldn't "svn ls -v URL" be a better choice here? There's no need to do
a checkout if you just want to see if a particular directory exists. If
that's not enough, "svn co -N URL" would work these days, too.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Blair Zajac <bl...@orcaware.com>.
Blair Zajac wrote:
>
> Arthur Bergman wrote:
> >
> > Yes, but I need to tag the imports, becomes kind of hard to the merge
> > otherwise? Why does svn_load_dirs need to checkout all the tags?
>
> It doesn't need to check out everything. I'll make a change that
> only checks out the specified directory being imported and the one
> directory that was tagged to run a consistency check.
Turns out there is a reason to check out the top level URL supplied
to svn_load_dirs. It checks out the top level directory so the
script can then check if any directories given to svn_load_dirs on
the command line need to be created.
So in your case,
> perl /usr/local/bin/svn_load_dirs.pl
> http://sky@svn.perl.org/ponie/vendor/parrot current
> /Users/sky/Documents/Projects/import/parrot/
It checkout out http://sky@svn.perl.org/ponie/vendor/parrot and then
checks if parrot exists. If it doesn't, then the script creates it
and then does an import.
So the code will have to check if things exist using hits against
the server.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Blair Zajac <bl...@orcaware.com>.
Arthur Bergman wrote:
>
> Yes, but I need to tag the imports, becomes kind of hard to the merge
> otherwise? Why does svn_load_dirs need to checkout all the tags?
It doesn't need to check out everything. I'll make a change that
only checks out the specified directory being imported and the one
directory that was tagged to run a consistency check.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Blair Zajac <bl...@orcaware.com>.
Arthur Bergman wrote:
>
> # $HeadURL:
> http://svn.collab.net/repos/svn/branches/release-0.24.2/tools/client
> -side/svn_load_dirs.pl.in $
> # $LastChangedDate: 2003-04-17 18:23:28 -0400 (Thu, 17 Apr 2003) $
> # $LastChangedBy: blair $
> # $LastChangedRevision: 5669 $
>
> Oki, I should update, I am running the 0.25 client so I now idea why my
> svn_load_dirs isn't from 0.25
Arthur,
There's a new version out that should fix the speed issue.
Check out
http://svn.collab.net/repos/svn/trunk/tools/client-side
to get the latest version.
Let me know if this solves the issue or if there are any other
problems.
One request. If you have any more issues with Subversion, please
send us an email on the users or dev mailing lists. We don't bite,
or if we do, we take small bites :)
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Arthur Bergman <ar...@fotango.com>.
On Thursday, July 31, 2003, at 07:52 pm, Blair Zajac wrote:
>>
>> If I do but it checks out http://sky@svn.perl.org/ponie/vendor/parro
>> which is huge
>
> Hmm, password protected site. It would be handy to have anonymous
> users with read-only access.
anon@svn works
>
>>
>> perl /usr/local/bin/svn_load_dirs.pl
>> http://sky@svn.perl.org/ponie/vendor/parrot current
>> /Users/sky/Documents/Projects/import/parrot/
>>
>> it works
>>
>> if I do
>>
>> perl /usr/local/bin/svn_load_dirs.pl -t 20030731
>> http://sky@svn.perl.org/ponie/vendor/parrot current
>> /Users/sky/Documents/Projects/import/parrot/
>
> Yes, performance is fine if you don't tag anything because no tag
> directories are created and you only check out current.
>
Yes, but I need to tag the imports, becomes kind of hard to the merge
otherwise? Why does svn_load_dirs need to checkout all the tags?
>>
>> It tells me after it has checked out everything
>> needs to create directroy /Users
>> needs to create directroy /Users/sky
>> needs to create directroy /Users/sky/.... you get the idea.
>
> This looks like a bug. There's no reason why the path to the directory
> being imported should appear in the Subversion repository.
>
> Which version of svn_load_dirs.pl are you using? There was a recent
> bug fix checked in that fixed issues when absolute path names were
> used.
>
>
# $HeadURL:
http://svn.collab.net/repos/svn/branches/release-0.24.2/tools/client
-side/svn_load_dirs.pl.in $
# $LastChangedDate: 2003-04-17 18:23:28 -0400 (Thu, 17 Apr 2003) $
# $LastChangedBy: blair $
# $LastChangedRevision: 5669 $
Oki, I should update, I am running the 0.25 client so I now idea why my
svn_load_dirs isn't from 0.25
Arthur
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Arthur Bergman <ar...@fotango.com>.
On Thursday, July 31, 2003, at 07:52 pm, Blair Zajac wrote:
>>>>
>>>> Doing a vendor checkin brining up parrot to latest version is a
>>>> major
>>>> pain the arse. The process alone of running svn_load_dirs takes
>>>> around
>>>> an hour, and then I have to tag it (because if you tell
>>>> svn_load_dirs
>>>> to tag things automatically it breaks). It also seems not to have
>>>> changed some stuff when other stuff has changed!
>>>> (http://svn.perl.org/ponie/vendor/parrot/current/config/auto/gcc.pl
>>>> is
>
> What about this file? How can this problem be reproduced?
>
I have no idea, in fact I have no clue what has happened with it. I
fixed in the repository now.
Arthur
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Blair Zajac <bl...@orcaware.com>.
Arthur Bergman wrote:
>
> On Thursday, July 31, 2003, at 06:54 pm, Blair Zajac wrote:
>
> > [cc'ing Arthur]
> >
> > Arthur wrote:
> >>
> >> Hi,
> >>
> >> Doing a vendor checkin brining up parrot to latest version is a major
> >> pain the arse. The process alone of running svn_load_dirs takes around
> >> an hour, and then I have to tag it (because if you tell svn_load_dirs
> >> to tag things automatically it breaks). It also seems not to have
> >> changed some stuff when other stuff has changed!
> >> (http://svn.perl.org/ponie/vendor/parrot/current/config/auto/gcc.pl is
What about this file? How can this problem be reproduced?
> >> one file that should have been updated).
> >
> > Hi Arthur,
> >
> > I'm curious about the specifics of this issue.
> >
> > How does it break?
> >
> > Where are the ponie tar's and what are the commands you're using? I'll
> > try to reproduce and fix the issues you're seeing.
> >
>
> If I do but it checks out http://sky@svn.perl.org/ponie/vendor/parro
> which is huge
Hmm, password protected site. It would be handy to have anonymous
users with read-only access.
>
> perl /usr/local/bin/svn_load_dirs.pl
> http://sky@svn.perl.org/ponie/vendor/parrot current
> /Users/sky/Documents/Projects/import/parrot/
>
> it works
>
> if I do
>
> perl /usr/local/bin/svn_load_dirs.pl -t 20030731
> http://sky@svn.perl.org/ponie/vendor/parrot current
> /Users/sky/Documents/Projects/import/parrot/
Yes, performance is fine if you don't tag anything because no tag
directories are created and you only check out current.
>
> It tells me after it has checked out everything
> needs to create directroy /Users
> needs to create directroy /Users/sky
> needs to create directroy /Users/sky/.... you get the idea.
This looks like a bug. There's no reason why the path to the directory
being imported should appear in the Subversion repository.
Which version of svn_load_dirs.pl are you using? There was a recent
bug fix checked in that fixed issues when absolute path names were
used.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Arthur Bergman <ar...@fotango.com>.
On Thursday, July 31, 2003, at 06:54 pm, Blair Zajac wrote:
> [cc'ing Arthur]
>
> Arthur wrote:
>>
>> Hi,
>>
>> Doing a vendor checkin brining up parrot to latest version is a major
>> pain the arse. The process alone of running svn_load_dirs takes around
>> an hour, and then I have to tag it (because if you tell svn_load_dirs
>> to tag things automatically it breaks). It also seems not to have
>> changed some stuff when other stuff has changed!
>> (http://svn.perl.org/ponie/vendor/parrot/current/config/auto/gcc.pl is
>> one file that should have been updated).
>
> Hi Arthur,
>
> I'm curious about the specifics of this issue.
>
> How does it break?
>
> Where are the ponie tar's and what are the commands you're using? I'll
> try to reproduce and fix the issues you're seeing.
>
If I do but it checks out http://sky@svn.perl.org/ponie/vendor/parro
which is huge
perl /usr/local/bin/svn_load_dirs.pl
http://sky@svn.perl.org/ponie/vendor/parrot current
/Users/sky/Documents/Projects/import/parrot/
it works
if I do
perl /usr/local/bin/svn_load_dirs.pl -t 20030731
http://sky@svn.perl.org/ponie/vendor/parrot current
/Users/sky/Documents/Projects/import/parrot/
It tells me after it has checked out everything
needs to create directroy /Users
needs to create directroy /Users/sky
needs to create directroy /Users/sky/.... you get the idea.
the process usually takes an hour or so, most time spent in the checkout
arthur
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Blair Zajac <bl...@orcaware.com>.
[cc'ing Arthur]
Arthur wrote:
>
> Hi,
>
> Doing a vendor checkin brining up parrot to latest version is a major
> pain the arse. The process alone of running svn_load_dirs takes around
> an hour, and then I have to tag it (because if you tell svn_load_dirs
> to tag things automatically it breaks). It also seems not to have
> changed some stuff when other stuff has changed!
> (http://svn.perl.org/ponie/vendor/parrot/current/config/auto/gcc.pl is
> one file that should have been updated).
Hi Arthur,
I'm curious about the specifics of this issue.
How does it break?
Where are the ponie tar's and what are the commands you're using? I'll
try to reproduce and fix the issues you're seeing.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by Blair Zajac <bl...@orcaware.com>.
"Jamin W. Collins" wrote:
>
> On Thu, Jul 31, 2003 at 09:43:30AM -0500, B. W. Fitzpatrick wrote:
> > > ------------
> > > Date: Thu, 31 Jul 2003 14:36:29 +0100
> > > Subject: Subversion
> > > From: Arthur Bergman <ar...@fotango.com>
> > > To: ponie-dev@perl.org
> > >
> > > Doing a vendor checkin brining up parrot to latest version is a major
> > > pain the arse. The process alone of running svn_load_dirs takes around
> > > an hour, and then I have to tag it (because if you tell svn_load_dirs
> > > to tag things automatically it breaks).
> >
> > Sounds like a bug in svn_load_dirs... was it reported?
>
> It was reported by me, not as a bug but as a question of why
> svn_load_dirs was functioning as it was. It's very inefficient at what
> it does if you have a few vendor revisions, since it first checks them
> ALL out.
Yes, this does get pretty slow.
I recall the reason I did this was when creating the tag, it compares
what ends up in the tag with what was requested to be checked in as
a consistency check for Subversion and svn_load_dirs.pl.
It could be modified to not check out the entire tag directory at all,
and make the tag copy directly on the server instead of in the wc, and
then check out the tag and do a diff to verify that everything was done
correctly.
I'll take a look at it.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: A real world user's impression of Subversion
Posted by "Jamin W. Collins" <jc...@asgardsrealm.net>.
On Thu, Jul 31, 2003 at 09:43:30AM -0500, B. W. Fitzpatrick wrote:
> > ------------
> > Date: Thu, 31 Jul 2003 14:36:29 +0100
> > Subject: Subversion
> > From: Arthur Bergman <ar...@fotango.com>
> > To: ponie-dev@perl.org
> >
> > Doing a vendor checkin brining up parrot to latest version is a major
> > pain the arse. The process alone of running svn_load_dirs takes around
> > an hour, and then I have to tag it (because if you tell svn_load_dirs
> > to tag things automatically it breaks).
>
> Sounds like a bug in svn_load_dirs... was it reported?
It was reported by me, not as a bug but as a question of why
svn_load_dirs was functioning as it was. It's very inefficient at what
it does if you have a few vendor revisions, since it first checks them
ALL out.
--
Jamin W. Collins
Remember, root always has a loaded gun. Don't run around with it unless
you absolutely need it. -- Vineet Kumar
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org