Discussion:
A couple more subversion notes
(too old to reply)
Daniel Berlin
2005-10-19 13:42:05 UTC
Permalink
1. The entire svn repo is currently 8.5 gig on disk (the cvs repo is 3.4
gig)

About 3 gig of this is crappy tag metadata (IE from tags that weird
things have been done to, etc, so that cvs2svn can't simply make copies
like subversion would have done originally).

The svn repo also contains more history than the old cvs server, since
it has old-gcc merged into it.

I expect the repo to grow pretty slowly in reality (though 8.5 gig for
16 years isn't too bad).

I'm working on patches for svn 1.4 that will reduce the repo size to
about 4-5 gig (conservatively high) through better compression.

2. If you want context diffs, or support for -p, you need to configure
an external diff. subversion's internal diff library always produces
unidiffs. It is also not as featureful as gnu diff. It was built
mainly so svn diff and friends would work without an external diff.

I have a link to how to configure an external diff on the wiki page.
It's really rather easy, and only has to be done once.

There is no need to use -N, as svn add is a command that does not
require write access.

3. Small operations (IE ls of random dirs, etc) are generally dominated
by the ssh handshake time. Using ssh multiplexing will significantly
speed these up.

4. For people using svk, the initial svk sync will probably take a while
if you directly svk mirror. It's probably a ton faster to rsync the
repo, svk mirror from that, and then change the source of the mirror
(which should work fine, AFAIK).

5. Lastly, just to be clear, if you guys don't think the benefits
outweigh the costs, we don't have to move.
So far, the amount of dissent i've heard is pretty small, but please, if
you don't want to move (or you do), please speak up, instead of silently
suffering (or silently being in joy).

Personally, i manage a bunch of branches, so subversion is a big win for
me.
It's nice to be able to merge and tag quickly and easily.

It's nice to be able to pull the revisions to the mainline simply by
using merge, instead of generating patches and reapplying them.

It's nice to be able to rsync the repo without it touching 80 billion
files.
etc

But if it's not a win for most of us, we probably shouldn't do it.
There is no perfect revision control system. None of the currently
production quality open source ones are any better.

--Dan
Paolo Bonzini
2005-10-19 13:54:09 UTC
Permalink
Post by Daniel Berlin
But if it's not a win for most of us, we probably shouldn't do it.
There is no perfect revision control system. None of the currently
production quality open source ones are any better.
I think it is natural that people start asking questions when they are
getting ready for the real thing. I think everybody is going to pleased
with the transition after a few weeks.

I was pleased when I moved my projects from CVS to arch, after one or
two weeks. And if I was pleased with arch, I guess it cannot go worse
with subversion...

I also have a question though. Is it possible to only mirror a few
given branches when setting up an svk repository? For me, for example,
local branches off the release branches and mainline would be more than
enough (and would allow me to get rid of the script I just described to
FX in the other thread...), and would save me presumably 4 gigs.

Paolo
Richard Guenther
2005-10-19 14:04:51 UTC
Permalink
Post by Paolo Bonzini
Post by Daniel Berlin
But if it's not a win for most of us, we probably shouldn't do it.
There is no perfect revision control system. None of the currently
production quality open source ones are any better.
I think it is natural that people start asking questions when they are
getting ready for the real thing. I think everybody is going to pleased
with the transition after a few weeks.
I was pleased when I moved my projects from CVS to arch, after one or
two weeks. And if I was pleased with arch, I guess it cannot go worse
with subversion...
I also have a question though. Is it possible to only mirror a few
given branches when setting up an svk repository? For me, for example,
local branches off the release branches and mainline would be more than
enough (and would allow me to get rid of the script I just described to
FX in the other thread...), and would save me presumably 4 gigs.
Yes, I just put some notes about how to do that on the wiki. Though try
using a local rsync copy of the svn repository for initial sync - it seems to
take ages if going over ssh+svn.

Richard.
Daniel Berlin
2005-10-19 14:23:39 UTC
Permalink
Post by Richard Guenther
Yes, I just put some notes about how to do that on the wiki. Though try
using a local rsync copy of the svn repository for initial sync - it seems to
take ages if going over ssh+svn.
Luckily, only one person needs to do it. We can then simply produce a
tarball of the .svk/local dir, let people download that, and you can add
that to your depotmap.

(i'm told by svk developers and users that this will work).

Richard Guenther actualy had a nice idea, which is to have three or four
of these

1. Full history
2. 4.0+
3. 3.4+
4. just HEAD

I'm happy to do this to get people started.
Post by Richard Guenther
Richard.
Daniel Berlin
2005-10-19 14:17:39 UTC
Permalink
Post by Paolo Bonzini
Post by Daniel Berlin
But if it's not a win for most of us, we probably shouldn't do it.
There is no perfect revision control system. None of the currently
production quality open source ones are any better.
I think it is natural that people start asking questions when they are
getting ready for the real thing. I think everybody is going to pleased
with the transition after a few weeks.
I was pleased when I moved my projects from CVS to arch, after one or
two weeks. And if I was pleased with arch, I guess it cannot go worse
with subversion...
I also have a question though. Is it possible to only mirror a few
given branches when setting up an svk repository?
You can simply tell svk to sync starting at a given revision, if
you don't want history back to the beginning of the planet
I'd find the oldest branch you want to care about, and then just sync
starting with that revision.

You can tell what revision a branch started at using a simple binary
search (assuming it was created once).

IE
svn ls svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch@<revision
number>

(This asks for the path as it existed in revision number.
If you used -r, it would find where it was copied from and follow it
back through renames, etc. There is a section on peg revs, as these are
called, in the book)

svn ls will give you an easily greppable error message if the path
doesn't exist.

It will take at max, log(num revisions)/log(2) (currently 12 :P) svn
ls's to find the beginning of the branch

I did it manually (and discovered, for example, that gcc-4_0-branch was
created in revision 95538

The following script, written by Richard Guenther, will do this for you:
#!/bin/sh

# search repository tag

if test -z "$1"; then
exit 1
fi

rev=`svn info $1/trunk | grep '^Revision:' | sed -e 's/Revision: //'`
echo trunk is at rev $rev
width=$[$rev / 2]
rev=$[$rev - $width]
while true; do
width=$[$width / 2]
echo svn info $1/$2@$rev
svn info $1/$2@$rev | grep "Not a valid URL"
if ! test $? == 0; then
echo - exists.
rev=$[$rev - $width]
else
rev=$[$rev + $width]
fi
if test $width == 0; then
break;
fi
done
Daniel Berlin
2005-10-19 14:16:11 UTC
Permalink
Post by Daniel Berlin
1. The entire svn repo is currently 8.5 gig on disk (the cvs repo is 3.4
gig)
Just to clarify, this is the entire repository on gcc.gnu.org, not the
checked out sources.
Arnaud Charlet
2005-10-19 14:44:59 UTC
Permalink
Here are my first impressions on trying to use subversion.

Note that I didn't go to any doc or wiki page yet, I simply copy/pasted
the commands I saw on the gcc list. I am familiar with cvs commands and
expect most things to be handled similarly.

- first check out:

svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk

took a lot of time, but I assume this is somewhat expected, and not really
a concern as I am not doing complete check outs often.

Then tried a few "cvs" things without much success:

$ cd trunk/gcc/ada
$ svn status Makefile.in
-> didn't get any answer
$ svn status --help Makefile.in
-> saw --verbose and --show-updates options

$ svn status --verbose Makefile.in
105364 103893 charlet Makefile.in

Not clear how to interpret this output without having to go to the doc,
no easy way to guess with my cvs knowledge, nor with my english knowledge.

I guess I was expecting something more verbose ala cvs, e.g a real "status"
in english, such as up-to-date, locally modified, needs merge, ...
instead of "nothing" or "M" which are rather cryptic for a subversion
novice.

$ svn status --show-updates Makefile.in
Status against revision: 105364

All right, I guess my Makefile.in file is at revision 105364.

Then:

$ svn log Makefile.in | more

figure out that the last two revs are 105364 and 103893 (and now I guess
I understand svn status --verbose output).

Note: coming from a cvs background, having non incremental version numbers
*per file* is very disruptive and non intuitive. I suspect it will take
me some time to adjust to this. Any suggestions/tricks welcome.

Now:

$ svn diff -r101581 -r103893 Makefile.in
svn: Multiple revision arguments encountered; try '-r M:N' instead of '-r M -r N'

All right, not very friendly to cvs users, but ok...

$ time svn diff -r101581:103893 Makefile.in
[repeated several times]

took between 16 and 22 seconds. 18 seconds typically.

Now, did a cvs diff -r1.120 -r1.121 Makefile.in

took between 3 and 5 seconds. 3.5 seconds typically.

Is there any way to improve such svn diff operation ? (Note that
I frequently do cvs diff on arbitrary revisions, not just the last two,
although doing cvs diff -rHEAD is probably the most frequent operation
I rely upon).

There is a factor more than 5 between svn diff and cvs diff in my set up
(svn 1.2.3, redhat 8), and this will likely significantly impact my work on
gcc

Log isn't as bad, but still annoying:

$ time svn log Makefile.in
gives about 5.5 seconds

$ time cvs log Makefile.in
gives about 4.5 seconds

Here, there's a 1 second difference (about 22%).

My 2 cents.

Arno
Richard Guenther
2005-10-19 14:52:42 UTC
Permalink
Post by Arnaud Charlet
Here are my first impressions on trying to use subversion.
Note that I didn't go to any doc or wiki page yet, I simply copy/pasted
the commands I saw on the gcc list. I am familiar with cvs commands and
expect most things to be handled similarly.
svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
took a lot of time, but I assume this is somewhat expected, and not really
a concern as I am not doing complete check outs often.
$ cd trunk/gcc/ada
$ svn status Makefile.in
-> didn't get any answer
$ svn status --help Makefile.in
-> saw --verbose and --show-updates options
$ svn status --verbose Makefile.in
105364 103893 charlet Makefile.in
Not clear how to interpret this output without having to go to the doc,
no easy way to guess with my cvs knowledge, nor with my english knowledge.
I guess I was expecting something more verbose ala cvs, e.g a real "status"
in english, such as up-to-date, locally modified, needs merge, ...
instead of "nothing" or "M" which are rather cryptic for a subversion
novice.
$ svn status --show-updates Makefile.in
Status against revision: 105364
All right, I guess my Makefile.in file is at revision 105364.
$ svn log Makefile.in | more
figure out that the last two revs are 105364 and 103893 (and now I guess
I understand svn status --verbose output).
Note: coming from a cvs background, having non incremental version numbers
*per file* is very disruptive and non intuitive. I suspect it will take
me some time to adjust to this. Any suggestions/tricks welcome.
$ svn diff -r101581 -r103893 Makefile.in
svn: Multiple revision arguments encountered; try '-r M:N' instead of '-r M -r N'
All right, not very friendly to cvs users, but ok...
$ time svn diff -r101581:103893 Makefile.in
[repeated several times]
took between 16 and 22 seconds. 18 seconds typically.
Now, did a cvs diff -r1.120 -r1.121 Makefile.in
took between 3 and 5 seconds. 3.5 seconds typically.
Is there any way to improve such svn diff operation ? (Note that
I frequently do cvs diff on arbitrary revisions, not just the last two,
although doing cvs diff -rHEAD is probably the most frequent operation
I rely upon).
There is a factor more than 5 between svn diff and cvs diff in my set up
(svn 1.2.3, redhat 8), and this will likely significantly impact my work on
gcc
I think people really want to use svk for their day-to-day work, because
1. such diffs are then local operations
2. you can have local branches which you can use instead of having
N checked out modified trees.

Richard.
Paolo Carlini
2005-10-19 14:56:23 UTC
Permalink
Post by Richard Guenther
I think people really want to use svk for their day-to-day work, because
1. such diffs are then local operations
2. you can have local branches which you can use instead of having
N checked out modified trees.
Feel free to stress this point on the wiki... ;)

Paolo.
Arnaud Charlet
2005-10-19 14:58:13 UTC
Permalink
Thanks for your reply and suggestion.
Post by Richard Guenther
I think people really want to use svk for their day-to-day work, because
1. such diffs are then local operations
2. you can have local branches which you can use instead of having
N checked out modified trees.
How are sync handled ? that is to say, how much time will it take to
do the update and how frequently do I need to do them.

How is diff -rHEAD handled with svk if my check out/database isn't synced ?

Also, I guess that would mean having 8.5 gigs dedicated
to the GCC rep (without talking about the check outs and builds) on
my machine. I know that disk space is cheap, but I would need to build a
new laptop or reformat my drive in order to achieve that... And still,
having 10gigs less on a laptop's hard drive is quite annoying.

Arno
Ranjit Mathew
2005-10-20 08:52:46 UTC
Permalink
Post by Arnaud Charlet
Also, I guess that would mean having 8.5 gigs dedicated
to the GCC rep (without talking about the check outs and builds) on
my machine. I know that disk space is cheap, but I would need to build a
new laptop or reformat my drive in order to achieve that... And still,
having 10gigs less on a laptop's hard drive is quite annoying.
8.5G seems to be the space needed on the server, *not*
on your local machine. For example, HEAD seems to
take 396M with CVS and 945M with SVN on one of the
PCs I tested (comparing "du -sh" output).

Note that each of the silly little files like "format",
"README.txt", etc. within the ".svn" folder take
up 4K each on partition I tested - the "README.txt"
files alone take up 6M in the checked-out "trunk"
sources.

Of course, the biggest savings would perhaps come
from not storing the "text-base" copies and letting
non-jet-setter hackers have the option of taking
the slight penalty of a lag when they do a diff
in exchange for a much reduced disc-space requirements.

Thanks,
Ranjit.

- --
Ranjit Mathew Email: rmathew AT gmail DOT com

Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
Arnaud Charlet
2005-10-20 08:58:14 UTC
Permalink
Post by Ranjit Mathew
8.5G seems to be the space needed on the server, *not*
on your local machine.
I believe you are confused: I was talking about a svk set up (as suggested
by the author of the email I was responding to) with a local
mirror of the repository in this message. 8.5G is for the local mirror,
it is not (even) counting the check out which does take almost a gig as
you said.

Arno
Richard Earnshaw
2005-10-20 09:02:50 UTC
Permalink
Post by Arnaud Charlet
I was talking about a svk set up (as suggested
by the author of the email I was responding to) with a local
mirror of the repository in this message. 8.5G is for the local mirror,
it is not (even) counting the check out which does take almost a gig as
you said.
According to the SVK wiki pages you don't need to mirror the entire
repository. You can do it from a specific version. So, for example,
you could mirror all versions since gcc-2.95 came out (or later if you
so wished).

That should cut down the size of the mirrored data significantly.

R.
Arnaud Charlet
2005-10-19 14:50:21 UTC
Permalink
Oh I forgot: tied a couple of svn commit operations, which,
after having set the EDITOR env variable, went fine, no troubles.

Arno
Andrew Haley
2005-10-19 15:04:02 UTC
Permalink
Post by Arnaud Charlet
Here are my first impressions on trying to use subversion.
Note that I didn't go to any doc or wiki page yet, I simply copy/pasted
the commands I saw on the gcc list. I am familiar with cvs commands and
expect most things to be handled similarly.
svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
took a lot of time, but I assume this is somewhat expected, and not really
a concern as I am not doing complete check outs often.
$ cd trunk/gcc/ada
$ svn status Makefile.in
-> didn't get any answer
$ svn status --help Makefile.in
-> saw --verbose and --show-updates options
$ svn status --verbose Makefile.in
105364 103893 charlet Makefile.in
Not clear how to interpret this output without having to go to the doc,
no easy way to guess with my cvs knowledge, nor with my english knowledge.
I guess I was expecting something more verbose ala cvs, e.g a real "status"
in english, such as up-to-date, locally modified, needs merge, ...
instead of "nothing" or "M" which are rather cryptic for a subversion
novice.
$ svn status --show-updates Makefile.in
Status against revision: 105364
All right, I guess my Makefile.in file is at revision 105364.
It seems to be incredibly hard to find out which branch a file is on.

[***@zorro gcc-head-test]$ svn status --verbose ChangeLog
105366 104478 mmitchel ChangeLog

Now, I happen to know that this is gcc-4_0-branch, and presumably if I
make any changes and check it back in that's where the changes will
go. But "svn ls branches" says

105358 dberlin Oct 16 01:53 gcc-4_0-branch/

So, how on Earth do I go from "105366 104478" to gcc-4_0-branch ?

Andrew.
Daniel Berlin
2005-10-19 15:11:30 UTC
Permalink
Post by Andrew Haley
It seems to be incredibly hard to find out which branch a file is on.
Huh?

The file is where it is.
Branches are just seperate directories.
If it's in the 4.0 directory, it's on the 4.0 branch

Revision numbers don't tell you what branch something is on.
They tell you what revision the repository is at, and the changesets
that have been applied to the repository.

If you want to know where the file is, ask where the file is :)
Post by Andrew Haley
105366 104478 mmitchel ChangeLog
Now, I happen to know that this is gcc-4_0-branch, and presumably if I
make any changes and check it back in that's where the changes will
go.
svn info ChangeLog
Post by Andrew Haley
But "svn ls branches" says
105358 dberlin Oct 16 01:53 gcc-4_0-branch/
Which is the last revision where gcc-4.0-branch was changed.
Post by Andrew Haley
So, how on Earth do I go from "105366 104478" to gcc-4_0-branch ?
You don't.
you use svn info on the ChangeLog.
and it will say:


Path: ChangeLog
Name: ChangeLog
URL: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/ChangeLog
Repository UUID: 284566a7-fc02-0410-aa54-b5c5f2f15645
Revision: 105366
Node Kind: file
Schedule: normal
Last Changed Author: ebotcazou
Last Changed Rev: 105335
Last Changed Date: 2005-10-12 18:14:32 -0400 (Wed, 12 Oct 2005)
Text Last Updated: 2005-10-19 11:07:35 -0400 (Wed, 19 Oct 2005)
Properties Last Updated: 2005-10-19 11:06:53 -0400 (Wed, 19 Oct 2005)
Checksum: 7b909ad6508f526b54a46d5d609022f8
Post by Andrew Haley
Andrew.
Andrew Haley
2005-10-19 15:21:25 UTC
Permalink
Post by Daniel Berlin
Post by Andrew Haley
It seems to be incredibly hard to find out which branch a file is on.
Huh?
The file is where it is.
Branches are just seperate directories.
If it's in the 4.0 directory, it's on the 4.0 branch
Revision numbers don't tell you what branch something is on.
They tell you what revision the repository is at, and the changesets
that have been applied to the repository.
If you want to know where the file is, ask where the file is :)
Post by Andrew Haley
105366 104478 mmitchel ChangeLog
Now, I happen to know that this is gcc-4_0-branch, and presumably if I
make any changes and check it back in that's where the changes will
go.
svn info ChangeLog
Aah, that's the key. Where we have one command in CVS, "status",
which tells us which branch a file is on and its status, we now have
two separate commands, "status" and "info". Easy enough, once you
know...

Andrew.
Giovanni Bajo
2005-10-19 15:21:05 UTC
Permalink
Post by Andrew Haley
It seems to be incredibly hard to find out which branch a file is on.
"svn info file". More typically, "snv info | grep URL" will tell you which
branch was the current working copy pulled from.
Post by Andrew Haley
105366 104478 mmitchel ChangeLog
Now, I happen to know that this is gcc-4_0-branch, and presumably if I
make any changes and check it back in that's where the changes will
go. But "svn ls branches" says
105358 dberlin Oct 16 01:53 gcc-4_0-branch/
So, how on Earth do I go from "105366 104478" to gcc-4_0-branch ?
Revisions and branches have nothing to do. It's not like CVS.
--
Giovanni Bajo
Daniel Berlin
2005-10-19 15:02:27 UTC
Permalink
Post by Arnaud Charlet
Here are my first impressions on trying to use subversion.
Note that I didn't go to any doc or wiki page yet, I simply copy/pasted
the commands I saw on the gcc list. I am familiar with cvs commands and
expect most things to be handled similarly.
svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
took a lot of time, but I assume this is somewhat expected, and not really
a concern as I am not doing complete check outs often.
$ cd trunk/gcc/ada
$ svn status Makefile.in
-> didn't get any answer
$ svn status --help Makefile.in
-> saw --verbose and --show-updates options
$ svn status --verbose Makefile.in
105364 103893 charlet Makefile.in
Not clear how to interpret this output without having to go to the doc,
no easy way to guess with my cvs knowledge, nor with my english knowledge.
I guess I was expecting something more verbose ala cvs, e.g a real "status"
in english, such as up-to-date, locally modified, needs merge, ...
instead of "nothing" or "M" which are rather cryptic for a subversion
novice.
$ svn status --show-updates Makefile.in
Status against revision: 105364
All right, I guess my Makefile.in file is at revision 105364.
$ svn log Makefile.in | more
figure out that the last two revs are 105364 and 103893 (and now I guess
I understand svn status --verbose output).
Note: coming from a cvs background, having non incremental version numbers
*per file* is very disruptive and non intuitive. I suspect it will take
me some time to adjust to this. Any suggestions/tricks welcome.
$ svn diff -r101581 -r103893 Makefile.in
svn: Multiple revision arguments encountered; try '-r M:N' instead of '-r M -r N'
All right, not very friendly to cvs users, but ok...
$ time svn diff -r101581:103893 Makefile.in
[repeated several times]
took between 16 and 22 seconds. 18 seconds typically.
Most of this is ssh overhead, because your diff is so small.

The ssh multiplexing stuff just written up on the wiki should help.

The svn protocol was built for multiple cheap connections, which is true
over tcp.

We use svn+ssh because that's the auth scheme cvs used, and all we have
implemented to auth people. Otherwise, we'd use svn+ssl or something.

However, this requires a bunch of svn protocol connections tunneled
through ssh connections :(

time svn diff -r101581:103893
svn://gcc.gnu.org/svn/gcc/trunk/gcc/ada/Makefile.in

(3-5 seconds)

vs

time svn diff -r101581:103893 svn
+ssh://gcc.gnu.org/svn/gcc/trunk/gcc/ada/Makefile.in

(15 seconds)

Sad, but true.

--Dan
Arnaud Charlet
2005-10-19 15:12:32 UTC
Permalink
Post by Daniel Berlin
Most of this is ssh overhead, because your diff is so small.
I disagree, the diff isn't small, it is of a typical/reasonable size I
would say.
Post by Daniel Berlin
The ssh multiplexing stuff just written up on the wiki should help.
Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
so I cannot test that right now.

Arno
Daniel Jacobowitz
2005-10-19 15:15:09 UTC
Permalink
Post by Arnaud Charlet
Post by Daniel Berlin
Most of this is ssh overhead, because your diff is so small.
I disagree, the diff isn't small, it is of a typical/reasonable size I
would say.
Post by Daniel Berlin
The ssh multiplexing stuff just written up on the wiki should help.
Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
so I cannot test that right now.
Or, use the svn protocol instead for read operations? I believe you
can do this using svn switch.
--
Daniel Jacobowitz
CodeSourcery, LLC
Daniel Jacobowitz
2005-10-19 15:20:04 UTC
Permalink
Post by Daniel Jacobowitz
Post by Arnaud Charlet
Post by Daniel Berlin
Most of this is ssh overhead, because your diff is so small.
I disagree, the diff isn't small, it is of a typical/reasonable size I
would say.
Post by Daniel Berlin
The ssh multiplexing stuff just written up on the wiki should help.
Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
so I cannot test that right now.
Or, use the svn protocol instead for read operations? I believe you
can do this using svn switch.
svn should probably be told to do that automatically for read operations,
if available. It will also take some load off the server for not
doing handshaking
and encryption.
I admit that'd be a pretty slick feature.
--
Daniel Jacobowitz
CodeSourcery, LLC
Richard Guenther
2005-10-19 15:18:26 UTC
Permalink
Post by Daniel Jacobowitz
Post by Arnaud Charlet
Post by Daniel Berlin
Most of this is ssh overhead, because your diff is so small.
I disagree, the diff isn't small, it is of a typical/reasonable size I
would say.
Post by Daniel Berlin
The ssh multiplexing stuff just written up on the wiki should help.
Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
so I cannot test that right now.
Or, use the svn protocol instead for read operations? I believe you
can do this using svn switch.
svn should probably be told to do that automatically for read operations,
if available. It will also take some load off the server for not
doing handshaking
and encryption.

Richard.
Daniel Berlin
2005-10-19 15:22:11 UTC
Permalink
Post by Daniel Jacobowitz
Post by Arnaud Charlet
Post by Daniel Berlin
Most of this is ssh overhead, because your diff is so small.
I disagree, the diff isn't small, it is of a typical/reasonable size I
would say.
Post by Daniel Berlin
The ssh multiplexing stuff just written up on the wiki should help.
Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
so I cannot test that right now.
Or, use the svn protocol instead for read operations? I believe you
can do this using svn switch.
Yes
you can svn switch --relocate to change the url of the repo
Daniel Berlin
2005-10-19 15:19:02 UTC
Permalink
Post by Arnaud Charlet
Post by Daniel Berlin
Most of this is ssh overhead, because your diff is so small.
I disagree, the diff isn't small, it is of a typical/reasonable size I
would say.
I mean bytewise, it is small compared to the overhead of ssh.
It's probably 2k compressed
:)
Gabriel Dos Reis
2005-10-20 06:34:48 UTC
Permalink
Arnaud Charlet <***@adacore.com> writes:

| > Most of this is ssh overhead, because your diff is so small.
|
| I disagree, the diff isn't small, it is of a typical/reasonable size I
| would say.
|
| > The ssh multiplexing stuff just written up on the wiki should help.
|
| Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
| so I cannot test that right now.

I have been following the discussion as someone who hasn't made the
move yet (and I should probably do so very soon because of releases,
but currently I've been travelling a lot and do not have reliable
connection all the way) and trying to learn.
My current impression is that each answer to issues people reported
(as to be expected in a move) is along the line of yet more
complicated settings. That gets me a bit worried about the inflation
of "new technology" requirements.
I just got a new laptop that I formatted for "typical" development
with dual boot. I'm worried about the 8 gigs stuff.

Please refrain from "here are $X, buy yourself a new harddrive".

-- Gaby
Giovanni Bajo
2005-10-19 15:05:44 UTC
Permalink
Post by Arnaud Charlet
Not clear how to interpret this output without having to go to the doc,
no easy way to guess with my cvs knowledge, nor with my english knowledge.
I guess I was expecting something more verbose ala cvs, e.g a real "status"
in english, such as up-to-date, locally modified, needs merge, ...
instead of "nothing" or "M" which are rather cryptic for a subversion
novice.
It's the same, with a minimal non-verbose output, and a default which does
not require any connection to the server. You'll learn to use "svn status"
without any argument to find out "what's up" in your working copy,
irrespective of the server. If it does not say anything, your working copy
is pristine.
Post by Arnaud Charlet
$ svn status --show-updates Makefile.in
Status against revision: 105364
This would show pending updates as you expect.
Post by Arnaud Charlet
Note: coming from a cvs background, having non incremental version numbers
*per file* is very disruptive and non intuitive. I suspect it will take
me some time to adjust to this. Any suggestions/tricks welcome.
I don't think there are suggestions or tricks. You'll just have to get used
to the idea that the changesets are atomic, and they uniquely identify the
whole tree. When you said that your repository is version 105364, your svn
status is empty, and you see a bug, I can download that very version and
reproduce it, without having to match your top of ChangeLog, or other weird
things.

Per-file, you can see the history to see when the file was changed. Noice
that you can use --verbose to see other files changed in the same commit,
which is very handy (no more wasted time looking for the whole patch in
gcc-cvs or in gcc-patches).
Post by Arnaud Charlet
took between 16 and 22 seconds. 18 seconds typically.
Now, did a cvs diff -r1.120 -r1.121 Makefile.in
took between 3 and 5 seconds. 3.5 seconds typically.
Out of curiosity, are you comparing anonymous CVS versus svn+ssh? In that
case, it's apple and oranges. Do some ssh multiplexing and get speed back.
Post by Arnaud Charlet
Is there any way to improve such svn diff operation ? (Note that
I frequently do cvs diff on arbitrary revisions, not just the last two,
although doing cvs diff -rHEAD is probably the most frequent operation
I rely upon).
"svk" is a tool that lets you mirror the entire repository (or a subset of),
checkout many copies from your local mirror, diff whatever with whatever,
commit into your local repository, and finally push changes into the
official repository. I believe it's going to be very handy for the average
GCC developer. People are still discussing about it (see other mails) and I
believe a Wiki page will be setup about it.
--
Giovanni Bajo
Daniel Jacobowitz
2005-10-19 15:19:36 UTC
Permalink
The main issue is really with svn status and the handling of versions and
branches which seems to be quite different and quite disruptive for cvs
users.
I think that "svn info" is a better match for "cvs status" than "svn
status" is.
--
Daniel Jacobowitz
CodeSourcery, LLC
Arnaud Charlet
2005-10-19 15:17:32 UTC
Permalink
Post by Giovanni Bajo
Out of curiosity, are you comparing anonymous CVS versus svn+ssh? In that
For your curiousity, no. I am comparing two write-access repositories
(CVS and svn+ssh).
Post by Giovanni Bajo
case, it's apple and oranges. Do some ssh multiplexing and get speed back.
I first need to update to openssh 4.0 which will take some time...

But indeed, if this single change gets speed comparable to cvs, I'll be
reasonably happy.

The main issue is really with svn status and the handling of versions and
branches which seems to be quite different and quite disruptive for cvs
users.
Post by Giovanni Bajo
"svk" is a tool that lets you mirror the entire repository (or a subset of),
checkout many copies from your local mirror, diff whatever with whatever,
commit into your local repository, and finally push changes into the
official repository. I believe it's going to be very handy for the average
GCC developer. People are still discussing about it (see other mails) and I
believe a Wiki page will be setup about it.
Thanks.
I'll wait for the outcome of this discussion. So far, it's not clear that svk
will fit well in my set up.

Arno
Giovanni Bajo
2005-10-19 15:39:23 UTC
Permalink
The main issue is really with svn status and the handling of versions and
branches which seems to be quite different and quite disruptive for cvs
users.
Branches is where we expect the most from SVN, compared to CVS. The wiki
part about management of branches is a little confusing, indeed. I'll try to
reword it to make it easier. There is also a little tool (svnmerge) which
helps managing branches.

If you care elaborating on which your typical cvs procedures for branch
management are (I'd separate release branches from dev branches for
clarity), I can work out for you the correct SVN counterparts, which - I'm
sure - they're going to be more than satisfying.
--
Giovanni Bajo
Andreas Schwab
2005-10-19 15:03:03 UTC
Permalink
Post by Daniel Berlin
3. Small operations (IE ls of random dirs, etc) are generally dominated
by the ssh handshake time. Using ssh multiplexing will significantly
speed these up.
How can I tell ssh not to barf if the ControlPath does not exist? Also,
you can't share the config file with an older ssh version because it will
barf about the unknown config option.

Andreas.
--
Andreas Schwab, SuSE Labs, ***@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Giovanni Bajo
2005-10-19 15:09:55 UTC
Permalink
Post by Andreas Schwab
Post by Daniel Berlin
3. Small operations (IE ls of random dirs, etc) are generally dominated
by the ssh handshake time. Using ssh multiplexing will significantly
speed these up.
How can I tell ssh not to barf if the ControlPath does not exist? Also,
you can't share the config file with an older ssh version because it will
barf about the unknown config option.
I put ControlPath in the config file, and then run "ssh -fMN host" at
startup. When is it barfing for you? If I remove the socket file, it just
does a normal connection.
--
Giovanni Bajo
Andreas Schwab
2005-10-19 15:26:42 UTC
Permalink
Post by Giovanni Bajo
I put ControlPath in the config file, and then run "ssh -fMN host" at
startup. When is it barfing for you?
According to the wiki ssh is supposed to ignore the controlpath when it
doesn't exist, but instead it barfs.
Post by Giovanni Bajo
If I remove the socket file, it just does a normal connection.
It doesn't for me.

$ ssh gcc.gnu.org
Couldn't connect to /var/tmp/schwab/ssh_%h: No such file or directory

Andreas.
--
Andreas Schwab, SuSE Labs, ***@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Giovanni Bajo
2005-10-19 15:35:25 UTC
Permalink
Post by Andreas Schwab
Post by Giovanni Bajo
If I remove the socket file, it just does a normal connection.
It doesn't for me.
$ ssh gcc.gnu.org
Couldn't connect to /var/tmp/schwab/ssh_%h: No such file or directory
Ah, maybe it's a later fix? I'm using:

$ ssh -V
OpenSSH_4.2p1, OpenSSL 0.9.7f 22 Mar 2005
--
Giovanni Bajo
Andreas Schwab
2005-10-19 16:04:11 UTC
Permalink
Post by Giovanni Bajo
$ ssh -V
OpenSSH_4.2p1, OpenSSL 0.9.7f 22 Mar 2005
Maybe, I'm using 4.1p1.

Andreas.
--
Andreas Schwab, SuSE Labs, ***@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Daniel Jacobowitz
2005-10-19 15:49:37 UTC
Permalink
Post by Andreas Schwab
Post by Giovanni Bajo
I put ControlPath in the config file, and then run "ssh -fMN host" at
startup. When is it barfing for you?
According to the wiki ssh is supposed to ignore the controlpath when it
doesn't exist, but instead it barfs.
Post by Giovanni Bajo
If I remove the socket file, it just does a normal connection.
It doesn't for me.
$ ssh gcc.gnu.org
Couldn't connect to /var/tmp/schwab/ssh_%h: No such file or directory
Yes, the lack of expanded %h means that you're looking at an older
version of OpenSSH; I guess the missing ControlPath support was also a
bug fix.
--
Daniel Jacobowitz
CodeSourcery, LLC
Daniel Jacobowitz
2005-10-19 15:16:26 UTC
Permalink
Post by Andreas Schwab
Post by Daniel Berlin
3. Small operations (IE ls of random dirs, etc) are generally dominated
by the ssh handshake time. Using ssh multiplexing will significantly
speed these up.
How can I tell ssh not to barf if the ControlPath does not exist? Also,
It shouldn't; it should automatically open a normal connection. This
may be a fix in newer versions of ssh.
Post by Andreas Schwab
you can't share the config file with an older ssh version because it will
barf about the unknown config option.
Yes; if you know how to pass arguments to SVN's invocation of ssh, you
can use that instead. I only put it in the config file because I
didn't feel like looking up the svn docs this morning.
--
Daniel Jacobowitz
CodeSourcery, LLC
Paolo Carlini
2005-10-19 15:06:23 UTC
Permalink
Post by Daniel Berlin
5. Lastly, just to be clear, if you guys don't think the benefits
outweigh the costs, we don't have to move.
So far, the amount of dissent i've heard is pretty small, but please, if
you don't want to move (or you do), please speak up, instead of silently
suffering (or silently being in joy).
Thanks Danny for asking. I'm reading the various messages coming to the list and, well, I'm *worried* the benefits will *not* outweigh the costs for many of us.

Sorry for the harsh and naive question: *which* are the benefits for people *not* managing many branches?

Paolo.
Steven Bosscher
2005-10-19 15:12:00 UTC
Permalink
Post by Paolo Carlini
Post by Daniel Berlin
5. Lastly, just to be clear, if you guys don't think the benefits
outweigh the costs, we don't have to move.
So far, the amount of dissent i've heard is pretty small, but please, if
you don't want to move (or you do), please speak up, instead of silently
suffering (or silently being in joy).
Thanks Danny for asking. I'm reading the various messages coming to the
list and, well, I'm *worried* the benefits will *not* outweigh the costs
for many of us.
Sorry for the harsh and naive question: *which* are the benefits for people
*not* managing many branches?
Hmm, let's see. The ones I care about most are:

1) Atomic commits, which make regression hunting a lot easier.
You can pinpoint exactly one patch, one revision, as the
thing to blame. Right now the regression hunter can from
time to time do checkouts from a data+time when someone was
just checking in a patch. With SVN, this is not a problem.

2) Ability to rename and move files. Have you ever looked at
the messy structure of gcc (i.e. the compiler proper)? And
don't you ever have the feeling that some libstdc++ file is
in the wrong place, but you don't want to move it because
it breaks the revision history? SVN helps here.

And less important but still nice:
3) Faster tagging, so you don't have to worry about not checking
out something when a gcc snapshot cron job is running
Giovanni Bajo
2005-10-19 15:32:48 UTC
Permalink
Post by Steven Bosscher
Post by Paolo Carlini
Thanks Danny for asking. I'm reading the various messages coming to the
list and, well, I'm *worried* the benefits will *not* outweigh the costs
for many of us.
Sorry for the harsh and naive question: *which* are the benefits for people
*not* managing many branches?
1) Atomic commits, which make regression hunting a lot easier.
You can pinpoint exactly one patch, one revision, as the
thing to blame. Right now the regression hunter can from
time to time do checkouts from a data+time when someone was
just checking in a patch. With SVN, this is not a problem.
2) Ability to rename and move files. Have you ever looked at
the messy structure of gcc (i.e. the compiler proper)? And
don't you ever have the feeling that some libstdc++ file is
in the wrong place, but you don't want to move it because
it breaks the revision history? SVN helps here.
3) Faster tagging, so you don't have to worry about not checking
out something when a gcc snapshot cron job is running
I'll add others:

4) Uniquely identification of a tree with a single number. "In my pristine
tree, revision 567890, I see this bug". That's unique.
5) Much much faster management of working copies: "svn diff" / "svn status"
do not require server connection. "what's up in my tree" and "what did I
change" can be answered in milliseconds.
6) Much easier reversion of patches for testing purposes, since you can
easily extract and revert an atomic changeset.
7) Much easier generation of proper diffs to send mail to the lists, since
you can "svn add" and "svn delete" without write access to the repository.
8) Fast switch of working copies from a branch to another, *maintaining* the
local changes. This is very handy.
9) Much easier backport of patches to release branches: "svn
merge -r123456", which also correctly remove/add/rename files as needed.
10) Getting rid forever of the problem with DOS newlines in source files.

I would also notice that most people don't RTFM. I spent many efforts in
writing the Wiki page, and the benefits of SVN are apparent if you spend
some time reading it and studying the thing a little. To make things better,
something *has* to change. You can't expect SVN to be *identical* to CVS,
but it's very very close.
--
Giovanni Bajo
Paolo Carlini
2005-10-19 15:40:30 UTC
Permalink
Post by Giovanni Bajo
4) Uniquely identification of a tree with a single number. "In my pristine
tree, revision 567890, I see this bug". That's unique.
5) Much much faster management of working copies: "svn diff" / "svn status"
do not require server connection. "what's up in my tree" and "what did I
change" can be answered in milliseconds.
6) Much easier reversion of patches for testing purposes, since you can
easily extract and revert an atomic changeset.
7) Much easier generation of proper diffs to send mail to the lists, since
you can "svn add" and "svn delete" without write access to the repository.
8) Fast switch of working copies from a branch to another, *maintaining* the
local changes. This is very handy.
9) Much easier backport of patches to release branches: "svn
merge -r123456", which also correctly remove/add/rename files as needed.
10) Getting rid forever of the problem with DOS newlines in source files.
I would also notice that most people don't RTFM. I spent many efforts in
writing the Wiki page, and the benefits of SVN are apparent if you spend
some time reading it and studying the thing a little. To make things better,
something *has* to change. You can't expect SVN to be *identical* to CVS,
but it's very very close.
Agreed, many thanks both to you and Steven.

Only one request from me: before the switch takes place, can you make
sure the instructions on the wiki are sufficiently complete and
incorporate all the latest advices about performance and so on? I think
this is an high priority and would even suggest delaying the switch if
we don't have those docs ready.

Thanks
Paolo.
Daniel Berlin
2005-10-19 18:36:08 UTC
Permalink
Post by Paolo Carlini
Post by Giovanni Bajo
I would also notice that most people don't RTFM. I spent many efforts in
writing the Wiki page, and the benefits of SVN are apparent if you spend
some time reading it and studying the thing a little. To make things better,
something *has* to change. You can't expect SVN to be *identical* to CVS,
but it's very very close.
Agreed, many thanks both to you and Steven.
Only one request from me: before the switch takes place, can you make
sure the instructions on the wiki are sufficiently complete and
incorporate all the latest advices about performance and so on? I think
this is an high priority and would even suggest delaying the switch if
we don't have those docs ready.
Well i guess i should aks the harsh question, which is, are these
advantages enough for you guys, or should we just not move?


Again, there are invariably some pains associated with any switch in
workflow :)
Paolo Carlini
2005-10-19 18:43:14 UTC
Permalink
Post by Daniel Berlin
Well i guess i should aks the harsh question, which is, are these
advantages enough for you guys, or should we just not move?
FWIW my personal opinion, indeed are enough from me (in particular, some
time ago, I have been discussing the diff preparation thing with Matt
Austern and others, thanks to Giovanni for reminding me that!),
*provided* the knowledgeable people volunteer to summarize on the wiki
also the latest advices about svk, ssh, and what else...

Paolo.
Andrew Haley
2005-10-19 18:44:38 UTC
Permalink
Post by Daniel Berlin
Post by Paolo Carlini
Post by Giovanni Bajo
I would also notice that most people don't RTFM. I spent many efforts in
writing the Wiki page, and the benefits of SVN are apparent if you spend
some time reading it and studying the thing a little. To make things better,
something *has* to change. You can't expect SVN to be *identical* to CVS,
but it's very very close.
Agreed, many thanks both to you and Steven.
Only one request from me: before the switch takes place, can you make
sure the instructions on the wiki are sufficiently complete and
incorporate all the latest advices about performance and so on? I think
this is an high priority and would even suggest delaying the switch if
we don't have those docs ready.
Well i guess i should aks the harsh question, which is, are these
advantages enough for you guys, or should we just not move?
Again, there are invariably some pains associated with any switch in
workflow :)
I've been browsing gcc change sets, and I have to say it's very nice
feature!

I'm in favour of the change if we can get a decent ssh tunnelling
solution sorted out so that "svn diff" is decently fast.

Andrew.
Diego Novillo
2005-10-19 18:46:07 UTC
Permalink
Post by Daniel Berlin
Well i guess i should aks the harsh question, which is, are these
advantages enough for you guys, or should we just not move?
I vote 'move'.
Mark Mitchell
2005-10-19 19:19:52 UTC
Permalink
Post by Diego Novillo
Post by Daniel Berlin
Well i guess i should aks the harsh question, which is, are these
advantages enough for you guys, or should we just not move?
I vote 'move'.
I've never used subversion -- this is the first time I know of that I've
typed "svn". I hate upgrades. Their cost is always bigger than
expected, even if you take that fact into account. (A variant of
Hofstdater's law...)

And, yet, I think we should move.

We've discussed this extensively at CodeSourcery, and I think everyone
is uniformly in favor. The superior branch facilities are a key
benefit. You got us through the Bugzilla transition, and that's working
well. Make it happen.
--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
(916) 791-8304
Joe Buck
2005-10-19 19:32:49 UTC
Permalink
Re: moving to subversion
Post by Mark Mitchell
We've discussed this extensively at CodeSourcery, and I think everyone
is uniformly in favor. The superior branch facilities are a key
benefit. You got us through the Bugzilla transition, and that's working
well. Make it happen.
It seems that there is consensus, but let's be sure. Certainly as the guy
who has to produce the releases, Mark's voice should weigh most heavily.

Are there any maintainers (folks in MAINTAINERS) who have objections or
concerns?

Going once, as they say ...
Bernd Schmidt
2005-10-19 21:04:47 UTC
Permalink
Post by Joe Buck
Are there any maintainers (folks in MAINTAINERS) who have objections or
concerns?
I haven't played with svn much, but from what I hear about the
advantages I'm all for it. cvs is so 20th century.


Bernd
Gabriel Dos Reis
2005-10-20 06:58:36 UTC
Permalink
Joe Buck <***@synopsys.COM> writes:

| Re: moving to subversion
|
| On Wed, Oct 19, 2005 at 12:19:52PM -0700, Mark Mitchell wrote:
| > We've discussed this extensively at CodeSourcery, and I think everyone
| > is uniformly in favor. The superior branch facilities are a key
| > benefit. You got us through the Bugzilla transition, and that's working
| > well. Make it happen.
|
| It seems that there is consensus, but let's be sure. Certainly as the guy
| who has to produce the releases, Mark's voice should weigh most heavily.
|
| Are there any maintainers (folks in MAINTAINERS) who have objections or
| concerns?

I've been travelling for the last couple or so weeks and did not have
the chance to test the svn repo. I'm following the discussion to get
an idea of the transition issues and I must say I do have concerns.
If to make this work, we have to require the latest system tools X, Y
and Z, then we're placing too high a barrier. Not everybody does its
development on its own laptop it can reformat or fiddle with. I'm
looking forward to solutions that lower the entry barrier,
specifically with repect too OpenSSH, diff and svk.

-- Gaby
Richard Guenther
2005-10-20 07:56:48 UTC
Permalink
On 20 Oct 2005 08:58:36 +0200, Gabriel Dos Reis
Post by Gabriel Dos Reis
| Re: moving to subversion
|
| > We've discussed this extensively at CodeSourcery, and I think everyone
| > is uniformly in favor. The superior branch facilities are a key
| > benefit. You got us through the Bugzilla transition, and that's working
| > well. Make it happen.
|
| It seems that there is consensus, but let's be sure. Certainly as the guy
| who has to produce the releases, Mark's voice should weigh most heavily.
|
| Are there any maintainers (folks in MAINTAINERS) who have objections or
| concerns?
I've been travelling for the last couple or so weeks and did not have
the chance to test the svn repo. I'm following the discussion to get
an idea of the transition issues and I must say I do have concerns.
If to make this work, we have to require the latest system tools X, Y
and Z, then we're placing too high a barrier. Not everybody does its
development on its own laptop it can reformat or fiddle with. I'm
looking forward to solutions that lower the entry barrier,
specifically with repect too OpenSSH, diff and svk.
If it is at all possible we should probably try to keep read-only CVS working
(and up-to-date) for HEAD and release-branches. This will allow occasional
contributors and technically-less-provided people to continue working in
submit-patch mode or in regular testing without raising the barrier for them.

I guess it should be possible with some commit-trigger scripts which svn
surely has?

Just another 2 cents,
Richard.
Paolo Carlini
2005-10-20 08:59:37 UTC
Permalink
Post by Richard Guenther
If it is at all possible we should probably try to keep read-only CVS working
(and up-to-date) for HEAD and release-branches. This will allow occasional
contributors and technically-less-provided people to continue working in
submit-patch mode or in regular testing without raising the barrier for them.
Irrespective of the other issues currently discussed, this is a very
good idea!

Paolo.
Eric Botcazou
2005-10-20 09:03:48 UTC
Permalink
Post by Paolo Carlini
Irrespective of the other issues currently discussed, this is a very
good idea!
Seconded!
--
Eric Botcazou
Joseph S. Myers
2005-10-20 09:06:37 UTC
Permalink
Post by Richard Guenther
If it is at all possible we should probably try to keep read-only CVS working
(and up-to-date) for HEAD and release-branches. This will allow occasional
contributors and technically-less-provided people to continue working in
submit-patch mode or in regular testing without raising the barrier for them.
Snapshots are available for FTP, have been available since before there
was anonymous CVS access and will continue to be available (I don't know
the exact status of the update of gcc_release to support subversion).
Snapshots provide a low-barrier access method for occasional contributors.

I don't think keeping the CVS repository up to date after the move to
subversion is worthwhile; it should of course remain available read-only
(changes disabled by making directories read-only and also preventing
commits in commitinfo / taginfo, plus anything else that helps to prevent
commits effectively) so old cvsweb URLs continue to work and people can
run "cvs diff" in modified working directories. Any means of keeping it
up to date would need to ensure that whatever hooks could commit to it
without leaving a window for any other commits, tags etc. to get it.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
***@polyomino.org.uk (personal mail)
***@codesourcery.com (CodeSourcery mail)
***@gcc.gnu.org (Bugzilla assignments and CCs)
Richard Guenther
2005-10-20 09:28:04 UTC
Permalink
Post by Joseph S. Myers
Post by Richard Guenther
If it is at all possible we should probably try to keep read-only CVS working
(and up-to-date) for HEAD and release-branches. This will allow occasional
contributors and technically-less-provided people to continue working in
submit-patch mode or in regular testing without raising the barrier for them.
Snapshots are available for FTP, have been available since before there
was anonymous CVS access and will continue to be available (I don't know
the exact status of the update of gcc_release to support subversion).
Snapshots provide a low-barrier access method for occasional contributors.
I agree that snapshots will work fine (and I just checked that we provide
patches).
Post by Joseph S. Myers
I don't think keeping the CVS repository up to date after the move to
subversion is worthwhile; it should of course remain available read-only
(changes disabled by making directories read-only and also preventing
commits in commitinfo / taginfo, plus anything else that helps to prevent
commits effectively) so old cvsweb URLs continue to work and people can
run "cvs diff" in modified working directories. Any means of keeping it
up to date would need to ensure that whatever hooks could commit to it
without leaving a window for any other commits, tags etc. to get it.
If there are technical issues the trouble is probably not worth it. It might
give some of us a more smooth transition though.

Richard.
Mark Mitchell
2005-10-20 14:46:52 UTC
Permalink
Post by Joseph S. Myers
I don't think keeping the CVS repository up to date after the move to
subversion is worthwhile
I agree.

I think that keeping CVS up-to-date is not a good use of resources; when
we switch, we switch. If for some reason we have to switch back, we
switch back. Let's not introduce last-minute feature creep.
--
Mark Mitchell
CodeSourcery, LLC
***@codesourcery.com
(916) 791-8304
Ian Lance Taylor
2005-10-20 15:52:14 UTC
Permalink
Post by Richard Guenther
If it is at all possible we should probably try to keep read-only CVS working
(and up-to-date) for HEAD and release-branches. This will allow occasional
contributors and technically-less-provided people to continue working in
submit-patch mode or in regular testing without raising the barrier for them.
I guess it should be possible with some commit-trigger scripts which svn
surely has?
I think that's a good idea. But I don't think it's fair to expect
Daniel to write it. It should be feasible for any sufficiently
interested person to write a script to dump out a patch from SVN,
queue up the patches, and apply them to the CVS repository. In fact
this doesn't even have to be driven from SVN commit scripts. It
obviously doesn't have to be a real-time operation, and could be done
at any time. For example a cron job could simply grab a diff of
everything since the last time it ran and then apply it to the CVS
repository. The only even slightly tricky part would be getting the
cvs add and rm commands right. We could run that script an hour.
Anybody who needs more cutting edge sources can switch to SVN.

Ian
Daniel Berlin
2005-10-20 16:21:32 UTC
Permalink
Post by Ian Lance Taylor
Post by Richard Guenther
If it is at all possible we should probably try to keep read-only CVS working
(and up-to-date) for HEAD and release-branches. This will allow occasional
contributors and technically-less-provided people to continue working in
submit-patch mode or in regular testing without raising the barrier for them.
I guess it should be possible with some commit-trigger scripts which svn
surely has?
I think that's a good idea. But I don't think it's fair to expect
Daniel to write it. It should be feasible for any sufficiently
interested person to write a script to dump out a patch from SVN,
queue up the patches, and apply them to the CVS repository. In fact
this doesn't even have to be driven from SVN commit scripts. It
obviously doesn't have to be a real-time operation, and could be done
at any time. For example a cron job could simply grab a diff of
everything since the last time it ran and then apply it to the CVS
repository. The only even slightly tricky part would be getting the
cvs add and rm commands right.
The diff driver for the bindings can tell you what files were added,
changed, copied, and removed between revisions.

This happens to get turned into unidiffs, but that's just what the "diff
generation" callbacks to.

You can do whatever you like with the information,.
Giovanni Bajo
2005-10-20 09:51:28 UTC
Permalink
I'm looking forward to solutions that lower the entry barrier,
specifically with repect too OpenSSH, diff and svk.
I'm going to write something in the wiki about svk. There's much FUD spreading
in this thread.
DanJ put up a wiki page on the OpenSSH configuration (which really could be
found with 3 minutes of googling, which is shorter than writing a mail asking
information about it [not speaking of you, gaby]). It might end up being not
strictly necessary if DannyB sets up a read-only svn:// repository (no SSH
required), but I'm sure that a release manager as you wants to have very fast
ssh connections to gcc.gnu.org also for other reasons.
I don't seem to recall that there was an unresolved/unclear issue about "diff".
Would you refresh me?

Giovanni Bajo
Andrew Haley
2005-10-20 10:01:52 UTC
Permalink
Post by Giovanni Bajo
I'm looking forward to solutions that lower the entry barrier,
specifically with repect too OpenSSH, diff and svk.
I'm going to write something in the wiki about svk. There's much FUD spreading
in this thread.
DanJ put up a wiki page on the OpenSSH configuration
http://gcc.gnu.org/wiki/SSH%20connection%20caching


(which really could be
Post by Giovanni Bajo
found with 3 minutes of googling, which is shorter than writing a mail asking
information about it [not speaking of you, gaby]). It might end up being not
strictly necessary if DannyB sets up a read-only svn:// repository (no SSH
required), but I'm sure that a release manager as you wants to have very fast
ssh connections to gcc.gnu.org also for other reasons.
I don't seem to recall that there was an unresolved/unclear issue about "diff".
Would you refresh me?
Giovanni Bajo
Arnaud Charlet
2005-10-20 10:11:20 UTC
Permalink
Post by Giovanni Bajo
DanJ put up a wiki page on the OpenSSH configuration (which really could be
found with 3 minutes of googling, which is shorter than writing a mail asking
information about it [not speaking of you, gaby]).
Well, with all your respect, you seem to be living in a different world than
mine.

In your world, everyone has an up-to-date version of every tool,
and have e.g. the latest OpenSSH and subversion clients installed
on his machine. In mine, this is clearly far from being the case:
no svn installed, and a 3.x openssh.

So with this world in mind, this is clearly not 3 minutes that are needed
to get the right set up.

Same for saying "this will be improved in the next version of svn".
It is assuming that upgrading versions of svn clients for people is a no
cost operation, which is again not the case in practice.

And maybe if svn 1.4 will improve such important improvements, it would
be a good idea to wait till svn 1.4 is outt so that people do not have to
upgrade multiple times to get "the expected" behavior.

Also remember that the vast majority of people accessing the cvs tree have
not even started looking at svn, so I am sure many more issues will come.
Post by Giovanni Bajo
It might end up being not
strictly necessary if DannyB sets up a read-only svn:// repository (no SSH
required), but I'm sure that a release manager as you wants to have very fast
ssh connections to gcc.gnu.org also for other reasons.
Same for me, I do not think it will be practical for me to switch between
svn and svn+ssh protocols.

Note that I am not at all opposed to this change.

I would simply like things to be stated in a fair way and as accurately as
possible so that people can decide on the best way to go, while a few svn
enthusiasts around here (not all of them fortunately) seem to be drawing a
"almost-perfect" picture which is not what people will be facing in reality
before quite some time (e.g. I see references to svn 1.4 while the latest
official release is 1.2.3).

So my gut feeling is that this switch is too early and that based on the
feedback received so far, we should aim at:

- getting more feedback from as much people as possible (and saying "reminder:
the switch will occur in a week" was relatively effective at that ;-)
- getting as much improvements in svn 1.4 as possible
- switch when 1.4.x is out and considered stable enough so that people
can use it heavily

Now, I understand that there are many other considerations around here
that will likely make this switch earlier, but anyway, my 2 euro cents.

Arno
Steven Bosscher
2005-10-20 10:49:14 UTC
Permalink
Post by Arnaud Charlet
And maybe if svn 1.4 will improve such important improvements, it would
be a good idea to wait till svn 1.4 is outt so that people do not have to
upgrade multiple times to get "the expected" behavior.
By then, I'm sure, people will find something else to complain about to
stop us from making the move.  For me SVN works just fine right now, and
I think for most people it does.
Post by Arnaud Charlet
Also remember that the vast majority of people accessing the cvs tree have
not even started looking at svn, so I am sure many more issues will come.
The change was announced months ago.  People could have looked at svn in
the mean time.  So this argument is moot.
Post by Arnaud Charlet
the switch will occur in a week" was relatively effective at that ;-)
- getting as much improvements in svn 1.4 as possible
- switch when 1.4.x is out and considered stable enough so that people
can use it heavily
This smells like the "committee approach" ;-)

Gr.
Steven
 
 
Ranjit Mathew
2005-10-20 11:24:16 UTC
Permalink
Post by Arnaud Charlet
In your world, everyone has an up-to-date version of every tool,
and have e.g. the latest OpenSSH and subversion clients installed
no svn installed, and a 3.x openssh.
So with this world in mind, this is clearly not 3 minutes that are needed
to get the right set up.
Same for saying "this will be improved in the next version of svn".
It is assuming that upgrading versions of svn clients for people is a no
cost operation, which is again not the case in practice.
You can certainly download the latest and the greatest version
of the required software and install it into a private
folder, say, "$HOME/wombat". This is not idle speculation, mind
you. This is exactly how I personally tested out the SVN
repository. The downloading, building and installation of
OpenSSL, OpenSSH and SVN (all latest stable versions) took
around 15 minutes and an "export PATH=$HOME/wombat/bin:$PATH"
later, I was ready to go.

This was Linux running on a P4 2.4GHz and your mileage
will most likely vary.
Post by Arnaud Charlet
And maybe if svn 1.4 will improve such important improvements, it would
be a good idea to wait till svn 1.4 is outt so that people do not have to
upgrade multiple times to get "the expected" behavior.
This is a point that I too would like to second.
- From what I read on this list, a stable SVN 1.4.x
is when a lot of barriers to SVN adoption would
be removed.

I'm not opposed per se to the shift to SVN, but
I sincerely feel that it is a *little* too early.

Thanks,
Ranjit.

- --
Ranjit Mathew Email: rmathew AT gmail DOT com

Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
Daniel Berlin
2005-10-20 12:42:25 UTC
Permalink
Post by Arnaud Charlet
Same for saying "this will be improved in the next version of svn".
It is assuming that upgrading versions of svn clients for people is a no
cost operation, which is again not the case in practice.
And maybe if svn 1.4 will improve such important improvements, it would
be a good idea to wait till svn 1.4 is outt so that people do not have to
upgrade multiple times to get "the expected" behavior.
Each version of svn will have important improvements, or else we
wouldn't give them major version numbers.

The thing i've discovered is that people will always find some issue
that bothers them, and raise it as "a major issue". This is because try
as you might, there *will be some workflow differences between cvs and
svn*.

This was true when we considered switching to svn 1.2, for example.

The reality is also that what your expectations are, are different than
what the expectations of others are.

All i can promise you is that i am busily coding solutions to the issues
people have raised.

So far, the feedback process has looked like:

1. I've given people months to consider the change, it's not until the
last few days that anybody who seems to complain even bothers to try it.
2. They then proceed to say "oh, we should wait another year till the
world is perfect".
3. We wait, next year comes, things are improved, but the world is still
not perfect. Meanwhile, switching becomes harder due to things you have
to emulate, and people getting more ingrained in the current tool
workflow.
4. Go to 1.

I don't say this because it isn't obvious, i say it because:
If i had been given feedback anytime between February and roughly the
middle of September, fixes for these issues would have been in
subversion 1.3.

In fact, the few issues raised to be so far in that time period (speed
of svn annotate, etc) were fixed by me, in subversion 1.3.

I have absolutely no reason to expect the feedback process to change if
we waited. I have absolutely no reason to believe this won't happen
again when svn 1.4 comes out.

It does not take long to fix these issues. The entire repo disk space
issue should be fixed within 1 week, and the entire repo should take
about 4-5 gig when i am done.
Post by Arnaud Charlet
(e.g. I see references to svn 1.4 while the latest
official release is 1.2.3).
1.3 should be out within 1 month. The first RC should be rolled in a
day or two.

--Dan
Gabriel Dos Reis
2005-10-20 13:12:30 UTC
Permalink
Daniel Berlin <***@dberlin.org> writes:

[...]

| I have absolutely no reason to expect the feedback process to change if
| we waited. I have absolutely no reason to believe this won't happen
| again when svn 1.4 comes out.

So why are people asked to voice their opinions if there is so much
distrust?

-- Gaby
Daniel Jacobowitz
2005-10-20 13:33:44 UTC
Permalink
Post by Arnaud Charlet
Post by Giovanni Bajo
DanJ put up a wiki page on the OpenSSH configuration (which really could be
found with 3 minutes of googling, which is shorter than writing a mail asking
information about it [not speaking of you, gaby]).
Well, with all your respect, you seem to be living in a different world than
mine.
In my world, I work with plenty of existing CVS repositories that take
longer to access than svn+ssh-without-connection caching, and it took
me about five minutes to look up how to use OpenSSH connection caching
once I knew that it existed.

I wouldn't be heartbroken to work with svn without it.
Post by Arnaud Charlet
In your world, everyone has an up-to-date version of every tool,
and have e.g. the latest OpenSSH and subversion clients installed
no svn installed, and a 3.x openssh.
Also in my world, building these in $HOME does not take very much
effort. Would you feel better about the transition if someone tested
and wrote up instructions on how to do this on various platforms?

It's really quite easy. It's not like you need the new SSH server,
just the unprivileged client.
Post by Arnaud Charlet
So my gut feeling is that this switch is too early and that based on the
the switch will occur in a week" was relatively effective at that ;-)
- getting as much improvements in svn 1.4 as possible
- switch when 1.4.x is out and considered stable enough so that people
can use it heavily
Others have already said this better, but we've been planning this
switch - and asking repeatedly for feedback - for a very long time now.
We chose not to say "it will happen in a week" until we felt that
everything was ready and most people were agreed, instead of
deliberately baiting the community to solicit feedback. I think that
was a good choice; I'm sorry that people are crawling out from
every which way now to object to the entire idea.

I eagerly look forward to svn. For me, the biggest draw is that cvs
update on branches takes a heinously long time and svn update on
branches does not.
--
Daniel Jacobowitz
CodeSourcery, LLC
Gabriel Dos Reis
2005-10-20 13:54:47 UTC
Permalink
Daniel Jacobowitz <***@false.org> writes:

[...]

| I think that
| was a good choice; I'm sorry that people are crawling out from
| every which way now to object to the entire idea.

I haven't seen people object to the idea of moving away from CVS.

I wonder exactly what types of feedback were "right" when people were
asked to voice their concerns from the testing.

-- Gaby
Steven Bosscher
2005-10-20 16:33:31 UTC
Permalink
Post by Daniel Jacobowitz
I eagerly look forward to svn.
Yay. Agreed.

Gr.
Steven

Daniel Berlin
2005-10-20 12:10:33 UTC
Permalink
Post by Giovanni Bajo
I'm looking forward to solutions that lower the entry barrier,
specifically with repect too OpenSSH, diff and svk.
I'm going to write something in the wiki about svk. There's much FUD spreading
in this thread.
DanJ put up a wiki page on the OpenSSH configuration (which really could be
found with 3 minutes of googling, which is shorter than writing a mail asking
information about it [not speaking of you, gaby]). It might end up being not
strictly necessary if DannyB sets up a read-only svn:// repository (no SSH
required), but I'm sure that a release manager as you wants to have very fast
ssh connections to gcc.gnu.org also for other reasons.
Just FYI, svn:// is set up and working, but is read-only.

Once svn:// has a secure transport layer (there is ongoing work on this
on the svnserve-ssl branch), we'll probably move away from svn+ssh.
Devang Patel
2005-10-20 00:08:44 UTC
Permalink
I've never used subversion before but I have subversion book on my desk.
It's time to open it very first time!

You say that it is easier to manage multiple branches using
subversion. This is enough to get my vote in favor of this transition.

My question is - What's the plan regarding cvs respoistory once svn
repository goes live on 22nd Oct ? Will it immediately become
read-only for everyone? Completely disapper? Use at your own risk? I
don't know?

Thanks for leading this transition,
-
Devang
Gabriel Dos Reis
2005-10-20 06:51:14 UTC
Permalink
Daniel Berlin <***@dberlin.org> writes:

| On Wed, 2005-10-19 at 17:40 +0200, Paolo Carlini wrote:
| > Giovanni Bajo wrote:
| >
| > >I'll add others:
| > >
| > >I would also notice that most people don't RTFM. I spent many efforts in
| > >writing the Wiki page, and the benefits of SVN are apparent if you spend
| > >some time reading it and studying the thing a little. To make things better,
| > >something *has* to change. You can't expect SVN to be *identical* to CVS,
| > >but it's very very close.
| > >
| > >
| > Agreed, many thanks both to you and Steven.
| >
| > Only one request from me: before the switch takes place, can you make
| > sure the instructions on the wiki are sufficiently complete and
| > incorporate all the latest advices about performance and so on? I think
| > this is an high priority and would even suggest delaying the switch if
| > we don't have those docs ready.
|
|
| Well i guess i should aks the harsh question, which is, are these
| advantages enough for you guys, or should we just not move?

Frankly, I don't know.

I would like to try first before making a definitive answer.
However, reading this thread, I find the inflation on supporting tools
and trickery requirements a bit daunting and too high an entry barrier.
If I have to install the lastest version of (system) tool X, Y and Z
-- which sometimes I can't on some of the machines I use for
development -- then I would say the answer is "no". But, as I
mentioned before, I have to try (probably not before next week).

I'm grateful to those who put effort in documenting the process, but
some of the replies I found here let me with an initial feeling of
deep skepticism.

| Again, there are invariably some pains associated with any switch in
| workflow :)

Indeed.

-- Gaby
Daniel Berlin
2005-10-19 15:45:08 UTC
Permalink
Post by Paolo Carlini
Post by Daniel Berlin
5. Lastly, just to be clear, if you guys don't think the benefits
outweigh the costs, we don't have to move.
So far, the amount of dissent i've heard is pretty small, but please, if
you don't want to move (or you do), please speak up, instead of silently
suffering (or silently being in joy).
Thanks Danny for asking. I'm reading the various messages coming to the list and, well, I'm *worried* the benefits will *not* outweigh the costs for many of us.
Sorry for the harsh and naive question: *which* are the benefits for people *not* managing many branches?
No, it's a perfectly fair question.

For people not managing any branches, your main advantage is changesets,
local operations for diff/add/delete/move/etc, renaming files, and
everything is atomic.
This means no more waiting for locks, even during commits.
The only time it will complain at you is if someone has touched the
exact path you are trying to commit since you last updated.

If you want to pull or apply patches, or reghunt, you can do it by
revision number, instead of tring to figure out what files made up a
patch.
You just ask it for "the diff that produced revision 12312 from revision
12311" and that includes *the entire diff*, not just the changes for a
single file.

Scripts are easier to produce, since anything you can do from the
command line, you can do with the bindings, very easily..

However, this is also true of *any* newer revision control system from
CVS.

They all share the "disadvantages" of subversion (global revision
numbers, carrying around more data, etc). In fact, AFAIK, none of them
actually let you work entirely disconnected without carrying repo
history (IE they won't go fetch things remotely in any automatic way),
in a way that a no-pristine copy subversion should.

So i guess the first decision is "do we want to stay with cvs forever,
or move to something different that has some advantages and some
disadvantages for most people, and very large advantages for some
people."

This *really* is the main decision. The rest is just timing.

I'm not trying to force anything on anyone.
If we truly want to stay with CVS forever, let's do that.

But you should know that it's a pain in the ass for people trying to
manage branches of any sort, do any sort of renames, and who don't want
to wait 30 minutes to commit things while people tag. We just don't
complain about those things because we had to live with them for so
long, we are used to this.

Also, considering we keep telling people to put changes and features on
branches, it is somewhat disingenuous to make that hard.
This is part of the reason people send large patches at the beginning of
stage1 that nobody has ever seen. Nobody wants to maintain a branch for
something small.

Now, personally, i'm confident the disk space issue (both mirroring the
remote repo, and working copy size) will go away in a newer version of
subversion, most likely 1.4 (unless disaster strikes, that's where the
patch i'm working on should end up).

svnserve is getting ssl and SASL support, which should be in 1.4, and we
would be able to use that in place of SVN+SSH, which should provide
stuff without the overhead of SSH.

However, there will always be issues, no matter when we move.
There is always something better down the pipe that will fix issues.

The longer you wait, the bigger your initial repos are going to be.
In february, the converted repo was 6 gig :)

cvs2svn is very good at what it does, but it has a very tough life
trying to convert file revisions into changesets, and make single
revision branches and tags out of mashed potatoes.

As for other VCS'en, Subversion has the advantage that i know how to fix
the issues we have, and will do so personally, if nobody else does.
This of course, will take time, but i can make that promise because i'm
a subversion committer, and i know how to get things into subversion
releases.


--Dan
Gabriel Dos Reis
2005-10-20 07:10:21 UTC
Permalink
Daniel Berlin <***@dberlin.org> writes:

[...]

| So i guess the first decision is "do we want to stay with cvs forever,
| or move to something different that has some advantages and some
| disadvantages for most people, and very large advantages for some
| people."
|
| This *really* is the main decision. The rest is just timing.

I think we should move away from CVS.

However, I do believe we should watch out for the inflation on
supporting technology requirements.

| I'm not trying to force anything on anyone.
| If we truly want to stay with CVS forever, let's do that.
|
| But you should know that it's a pain in the ass for people trying to
| manage branches of any sort, do any sort of renames, and who don't want
| to wait 30 minutes to commit things while people tag. We just don't
| complain about those things because we had to live with them for so
| long, we are used to this.

The Axiom Computer Algebra System project

http://www.axiom-developer.org/

uses "CVS" for mainline most people people can check out; it uses
"arch" for manging branches where developers do experiments. Once an
experiment is deemed successful, it is merged to mainline, synced with
the CVS version. So, those people not interested in growing branches
only pay for what they use. Other developers with more branch demands
have their cake and can eat it.
I don't know how that may work or may not for GCC.

-- Gaby
Paolo Bonzini
2005-10-20 07:53:21 UTC
Permalink
Post by Gabriel Dos Reis
uses "CVS" for mainline most people people can check out; it uses
"arch" for manging branches where developers do experiments.
I found arch very interesting, and I am using it for GNU sed and GNU
Smalltalk. I liked very much the idea of working offline, and the very
small requirements that are placed on the server (you only need a HTTP
server with support for FTP or SFTP uploads). The latter is probably
the only reason why I won't switch away from arch for a while.

It is also extremely nice to make queries such as "tell me which patches
I applied into the stable branch, coming from the development branch".

On the other hand, it simply does not scale. For GNU Smalltalk, which
has a 4 megabyte tarball and 1084 versioned files, it takes some 20
seconds to do a commit (I'm going by memory, maybe it's more).
Performance improvements have been made in the last few months, as well
as user interface improvements, and I have not yet upgraded; but the
overall picture is the same.

Personally, I have been grateful that my regression-fix patches touch
only one or two files plus the ChangeLog. It's been an annoyance to
backport them even if they were this simple. With arch I simply did

tla replay smalltalk--devo--2.2--patch-45
tla commit

and with subversion it is more or less the same.

Yes, it requires more setup. On the other hand, I never knew about
connection multiplexing for example, and I think I'll use it for other
machines I often ssh to (not only gcc.gnu.org), now that I know about it.

Paolo
Richard Kenner
2005-10-19 19:48:24 UTC
Permalink
Are there any maintainers (folks in MAINTAINERS) who have objections or
concerns?

Well, I haven't tried it myself yet, so what I'm going by is hearsay but
I do share the concern that it's looking like this is a change that may
make the common things harder and slower in order to make the less common
operations faster and/or easier. If so, that may not be the right tradeoff.
Giovanni Bajo
2005-10-19 20:18:58 UTC
Permalink
Post by Joe Buck
Are there any maintainers (folks in MAINTAINERS) who have objections or
concerns?
Well, I haven't tried it myself yet, so what I'm going by is hearsay but
I do share the concern that it's looking like this is a change that may
make the common things harder and slower in order to make the less common
operations faster and/or easier. If so, that may not be the right tradeoff.
I understand the concern, but let me assure you: I strongly believe that
this is not true. The only issue here is that people are trying to configure
SVN using our Wiki page as the only reference (and not everybody even did
that). Daniel and I wrote that page, but it is not meant to contain the
answers for all the questions, nor the solve all configuration problems. We
*never* had such a page for CVS as well: if it didn't work, people simply
googled until they found the solution.

Yet, to help the transition, we *are* preparing a documentation and we *are*
helping people moving. There will be issues in the transition. But the
result is that the common things will be faster and easier, and the less
common things will be so incredibly faster and easier that might become more
common about hackers -- which I see as a good thing.
--
Giovanni Bajo
Eric Botcazou
2005-10-20 09:01:51 UTC
Permalink
Post by Giovanni Bajo
Post by Richard Kenner
Well, I haven't tried it myself yet, so what I'm going by is hearsay but
I do share the concern that it's looking like this is a change that may
make the common things harder and slower in order to make the less common
operations faster and/or easier. If so, that may not be the right tradeoff.
I understand the concern, but let me assure you: I strongly believe that
this is not true.
I've never created/managed branches or tagged anything in the GCC tree. The
important things to me are:
- time to do a complete check-out on mainline/branch
- time to do an update on mainline/branch
- time to do a diff on mainline/branch
- time to do a commit on mainline/branch
- space needed locally for mainline/branch

Could you give realistic estimates of the change cvs->svn for them in terms of
percentage or ratio?

And finally:
- portability of svn to non-Linux systems

Thanks in advance.
--
Eric Botcazou
Steven Bosscher
2005-10-20 09:08:44 UTC
Permalink
Post by Eric Botcazou
- portability of svn to non-Linux systems
http://subversion.tigris.org/faq.html#portability

Gr.
Steven
 
 
Giovanni Bajo
2005-10-20 09:37:37 UTC
Permalink
Post by Eric Botcazou
I've never created/managed branches or tagged anything in the GCC
- time to do a complete check-out on mainline/branch
Check-out is 30% slower because of the time needed to write the duplicate local
copy. On the other hand, there is a nice option "svn switch" which lets you
switch a working copy tree from mainling to any branch and viceversa just by
downloading the delta between the two, so much faster than checking out
everything from scratch. I can think of this workflow:

- svn co path/to/mainline patch-sparc-frame-pointer (checkout pristine tree
to work on a specific patch)
- Write/test patch on mainline. Review/commit it. Committed as r1234567 (single
number identifies changes to 10 files, 1 rename, 2 deletions).
- From within .path-sparc-frame-pointer directory, svn switch
path/to/gcc40branch (switch to 4.0 branch)
- Backport patch: svn merge -r1234567 /path/to/mainline (automatically
rename, delete, apply modifies).
- Test/commit.
- svn switch path/to/gcc34/branch (switch to 3.4 branch)
- etc.

So, even if the initial checkout is slower, you have to do it less often.
Post by Eric Botcazou
- time to do an update on mainline/branch
When updating, cvs/svn first try to find out what needs to be updated (in rough
terms) and then start downloading the updates. The latter part (download) is
obviously the same, as they both download compressed delta over the network.
The former part is many times faster in svn, and takes the same time on
branches or mailine (while CVS was much slower in the branch) You'll find out
that, after you type "svn up", it'll start downloading the first file *much
faster* than it used to do with cvs, especially on a branch.
Post by Eric Botcazou
- time to do a diff on mainline/branch
"svn diff" is a disconnected operation, requires no server access, so it takes
milliseconds. "cvs diff" is dominated by network connection, so it can take a
while. Also "svn diff" can handle new and removed files, as you can easily do
"svn add/svn remove" on any file, since they don't write anything to the
server. Also, the new "svn status" (which is not like cvs status) shows you the
current status of your working copy (which files are added, removed, modified,
unknown) in milliseconds because it's a disconnected operation (again).
Post by Eric Botcazou
- time to do a commit on mainline/branch
Again, much faster in SVN, and it takes the same time on mainline/branches. CVS
used to do pretty slow at this.
Post by Eric Botcazou
- space needed locally for mainline/branch
Each working copy will take twice the space amount. If you add that to the
usual build directory associated with each tree, the difference in
"space-per-real-word-tree" is smaller, but it's still very noticeable. This is
issue will be probably fixed in newer SVN versions. For now, if disk space is
critical, one solution would be to use the 'svk' client tool, which offers many
other benefits.
Post by Eric Botcazou
- portability of svn to non-Linux systems
This has been answered already. It should not be an issue.

Giovanni Bajo
Arnaud Charlet
2005-10-20 09:45:10 UTC
Permalink
A few comments, since your message makes it sound like everything is
better, which is not true in reality.
Post by Giovanni Bajo
Post by Eric Botcazou
- time to do a diff on mainline/branch
"svn diff" is a disconnected operation, requires no server access, so it takes
milliseconds. "cvs diff" is dominated by network connection, so it can take a
while. Also "svn diff" can handle new and removed files, as you can easily do
That's not true: most svn diff operations are network driven such as
svn diff -rHEAD, -rrev, -rrev1:rev1, etc... as shown by my experiments and
following answers.
Post by Giovanni Bajo
Post by Eric Botcazou
- space needed locally for mainline/branch
Each working copy will take twice the space amount.
It's actually more 3x the space, see figures already given (about 340 megs
for cvs, and 950 for svn).
Post by Giovanni Bajo
Post by Eric Botcazou
- portability of svn to non-Linux systems
This has been answered already. It should not be an issue.
Note that I found it a real pain to have to install so much dependency package
on my linux system, so I suspect building the whole dependency packages under
non linux systems might be slghtly of a pain. And I am not done yet with
the OpenSSH update which seems kind of madatory to do any practical work.

So doing a full installation of the whole svn suite, plus OpenSSH 4.2,
plus svk which many people have already suggested is I suspect a non
trivial task on most non linux systems, even if these packages are
portable.

Arno
Giovanni Bajo
2005-10-20 10:06:22 UTC
Permalink
Post by Arnaud Charlet
Post by Giovanni Bajo
Post by Eric Botcazou
- portability of svn to non-Linux systems
This has been answered already. It should not be an issue.
Note that I found it a real pain to have to install so much
dependency package on my linux system, so I suspect building the
whole dependency packages under non linux systems might be slghtly of
a pain. And I am not done yet with
the OpenSSH update which seems kind of madatory to do any practical work.
Yes. I don't remember if there are issues with setting up a svn:// only
repository, which doesn't go through SSH.

Even if we assume that it's impossible to upgrade OpenSSH on a given platform
for some weird reason, the problem is probably going to be fixed by SVN 1.4 and
the new svn+ssl:// protocol. Meanwhile, unlucky people will have to live with a
slower "svn diff -rR1 -rR2" remote operation. Sorry about that, but let's not
remember of the other dozens which works on branches and can do a merge in
seconds instead of literally *hours*, and so on.

I don't think we can uniformly win everywhere, right now. I believe I have
already shown and spoken about many day-to-day advantages even for people
working only on mainline/release branches, and I'm sure that people that wanted
to listen have understood. Maybe somebody gave the wrong impression that
changing SCM was a thing with no issue in the transition, and no regression
whatsoever for every corner case possible. It's not like that (and we GCC
developers should know better about small regressions falling out of huge
improvements!)

CVS is a dead trail, and it's a huge bottleneck for many of us. SVN offers
many, many improvements for everybody, and a few regressions which are not even
by design and will be fixed someday (if we are lucky, in the next few months).
I believe we should all try to live with that.

As for your specific case, Arnaud, I assume that you do much SCM work, given
your "merge-centric" position. I'm more than happy to help you through this
transition and see if we can find out ways to improve your workflow with SVN.
As I told you in another mail, if you are interested, just provide me with more
information and let's see if we can work out something cool for you (even in
private mail, if you prefer for some reason).

Giovanni Bajo
Gabriel Dos Reis
2005-10-20 12:09:45 UTC
Permalink
"Giovanni Bajo" <***@develer.com> writes:


[...]

| Even if we assume that it's impossible to upgrade OpenSSH on a given platform
| for some weird reason,

I appreciate your effort in this, but I strongly suggest that you
refrain from calling reasons why people can't install the latest
versions of supporting tools "weird".

| the problem is probably going to be fixed by SVN 1.4 and
| the new svn+ssl:// protocol. Meanwhile, unlucky people will have to live with a
| slower "svn diff -rR1 -rR2" remote operation. Sorry about that, but let's not
| remember of the other dozens which works on branches and can do a merge in
| seconds instead of literally *hours*, and so on.

I was fearing that. I am of the opinion that we wait for a stable SVN 1.4.

-- Gaby
Paolo Bonzini
2005-10-20 12:46:36 UTC
Permalink
Post by Gabriel Dos Reis
| Even if we assume that it's impossible to upgrade OpenSSH on a given platform
| for some weird reason,
I appreciate your effort in this, but I strongly suggest that you
refrain from calling reasons why people can't install the latest
versions of supporting tools "weird".
I agree. For example, Fink on the Mac only has svn 1.1 (not that this
is a showstopper IMHO), and Debian testing is "stuck" with the latest
3.8 openssh.
Post by Gabriel Dos Reis
| the problem is probably going to be fixed by SVN 1.4 and
| the new svn+ssl:// protocol. Meanwhile, unlucky people will have to live with a
| slower "svn diff -rR1 -rR2" remote operation.
Or write a script gccdiff that, for now, invokes svn on the read-only
svn:// script. It will go away with SVN 1.4.

I think that "moving away" from svn+ssh should not mean disabling --
just making it the not-preferred way for connecting.

Also, I see how this cannot be an option for somebody, but the mirror
can be remote (e.g. NFS-mounted) if you are using svk. Still (unlike
with a rsync CVS repository), you could push changes to the main GCC
repository. I think that in the end I'll put the svk mirror somewhere
on a university server. Of course you lose the offline operation that
Giovanni likes so much :-) but it's just like CVS.

Paolo
Giovanni Bajo
2005-10-20 12:57:49 UTC
Permalink
Post by Gabriel Dos Reis
Post by Giovanni Bajo
Even if we assume that it's impossible to upgrade OpenSSH on a given
platform for some weird reason,
I appreciate your effort in this, but I strongly suggest that you
refrain from calling reasons why people can't install the latest
versions of supporting tools "weird".
Wrong choice of words, I apologize. I should have written "any given
reason", or simply "any reason".
Post by Gabriel Dos Reis
Post by Giovanni Bajo
the problem is probably going to be fixed by SVN 1.4 and
the new svn+ssl:// protocol. Meanwhile, unlucky people will have to live
with a slower "svn diff -rR1 -rR2" remote operation. Sorry about that,
but
Post by Gabriel Dos Reis
Post by Giovanni Bajo
let's not remember of the other dozens which works on branches and can do
a merge in seconds instead of literally *hours*, and so on.
I was fearing that. I am of the opinion that we wait for a stable SVN 1.4.
I would like to notice that a fair comparison should take into account the
fact that a single "svn diff" shows a whole changeset of changes (accounting
multiple files). With cvs, you might need to run multiple "cvs diff" (with
multiple SSH handshakes), plus the time to write all those different
revision numbers for each file. So, while the raw time for a single command
is slower, I believe that, in the common case, the operation still ends up
being faster, if expressed in "seconds to do what I want".

In other words, what I see mostly in this thread is that people are worried
because of what we usually call "micro-benchmarks" (e.g. "raw cvs diff time
for a single time across two revisions"), which is of course important (and
svn is mostly faster except a couple of corner-cases); but some seem to miss
that real-world workflow benchmarks (e.g. "time to backport a patch") are
several times better with svn, because of the higher-level commands and
concepts it provides.

I'd also remember that this issue (diff of a single file across SSH being
slower) can be fixed by either an OpenSSH upgrade (which should be flawless
in many cases), or a svn:// readonly access (which I still have to
understand if it can be done), or the use of svk which lets you mirror part
of the repository (including history) locally (e.g. everything since gcc
3.0) so that all the diff/checkout/switch/whatnot operations are blazingly
fast (at the expense of some disk space).
--
Giovanni Bajo
Gabriel Dos Reis
2005-10-20 13:23:55 UTC
Permalink
"Giovanni Bajo" <***@develer.com> writes:

[...]

| In other words, what I see mostly in this thread is that people are worried
| because of what we usually call "micro-benchmarks" (e.g. "raw cvs diff time
| for a single time across two revisions"),

People have been asked to voice their concerns and I think so far what
we're seeing is expected. People are concerned about the benefits
they get compared to the costs. Those who do regular diffs across
versions are concerned about the efficiency of those operations in the
new system. So they go and do measurements. Disk space is an issue
too. So is upgrade to new tools. Labelling it "micro-benchmarks"
will not change the reality for them. I believe you have to admit
that not everybody is going to benefit equally from the system. And
given that, I think one should pay respect to people's concerns and
constraints.

| which is of course important (and
| svn is mostly faster except a couple of corner-cases); but some seem to miss
| that real-world workflow benchmarks (e.g. "time to backport a patch") are
| several times better with svn, because of the higher-level commands and
| concepts it provides.

if that is indeed the case, then it will come true to them not
necessarily because they have been labelled "marginals" or "myopic".

-- Gaby
Daniel Berlin
2005-10-20 13:40:29 UTC
Permalink
Post by Giovanni Bajo
I'd also remember that this issue (diff of a single file across SSH being
slower) can be fixed by either an OpenSSH upgrade (which should be flawless
in many cases), or a svn:// readonly access (which I still have to
understand if it can be done),
svn:// readonly access is up and running.
Just remove the +ssh from your url.

The only reason we don't use svn:// right now is that it would require
transmitting passwords in plaintext.

--Dan
Bobby McN
2005-10-20 14:39:45 UTC
Permalink
Post by Daniel Berlin
Post by Giovanni Bajo
I'd also remember that this issue (diff of a single file across SSH being
slower) can be fixed by either an OpenSSH upgrade (which should be flawless
in many cases), or a svn:// readonly access (which I still have to
understand if it can be done),
svn:// readonly access is up and running.
Just remove the +ssh from your url.
The only reason we don't use svn:// right now is that it would require
transmitting passwords in plaintext.
--Dan
Daniel, I don't have an account with the repository.
How would I set my computer up to get the gcc code anonymously?
All i do is compile the code to make sure it will work with i686-pc-cygwin.
Bobby
Daniel Berlin
2005-10-20 16:20:17 UTC
Permalink
Post by Bobby McN
Daniel, I don't have an account with the repository.
How would I set my computer up to get the gcc code anonymously?
All i do is compile the code to make sure it will work with i686-pc-cygwin.
Bobby
You can follow the directions that exist on the wiki, except remove +ssh
from the url's.

--Dan
Daniel Berlin
2005-10-20 13:37:23 UTC
Permalink
Post by Gabriel Dos Reis
[...]
| Even if we assume that it's impossible to upgrade OpenSSH on a given platform
| for some weird reason,
I appreciate your effort in this, but I strongly suggest that you
refrain from calling reasons why people can't install the latest
versions of supporting tools "weird".
| the problem is probably going to be fixed by SVN 1.4 and
| the new svn+ssl:// protocol. Meanwhile, unlucky people will have to live with a
| slower "svn diff -rR1 -rR2" remote operation. Sorry about that, but let's not
| remember of the other dozens which works on branches and can do a merge in
| seconds instead of literally *hours*, and so on.
svn diff -r1:r2 is only slow in the very small diff case, where ssh
handshake time dominates the amount of data to be transferred.

Even then, if you do it as svn diff -r1:r2 svn://<path>, it will work
faster than cvs.

Yes, you do have to get used to doing things differently.
This is just a fact of switching.

--Dan
Gabriel Dos Reis
2005-10-20 13:46:15 UTC
Permalink
Daniel Berlin <***@dberlin.org> writes:

| > | the problem is probably going to be fixed by SVN 1.4 and
| > | the new svn+ssl:// protocol. Meanwhile, unlucky people will have to live with a
| > | slower "svn diff -rR1 -rR2" remote operation. Sorry about that, but let's not
| > | remember of the other dozens which works on branches and can do a merge in
| > | seconds instead of literally *hours*, and so on.
| >
|
| svn diff -r1:r2 is only slow in the very small diff case, where ssh
| handshake time dominates the amount of data to be transferred.

Good to know.

-- Gaby
Marcin Dalecki
2005-10-20 10:45:33 UTC
Permalink
Post by Arnaud Charlet
Note that I found it a real pain to have to install so much
dependency package
on my linux system, so I suspect building the whole dependency
packages under
non linux systems might be slghtly of a pain.
This is not the case. This is only due to the idiotic behaviour of
the common linux vendors, which pulverize every single piece of
software in to as many shared library packages as possible. The svn
tarball as downloaded doesn't require you to install any external
libraries - it contains them and the default build will just feed on
what it contains.
Richard Guenther
2005-10-20 10:31:09 UTC
Permalink
Post by Giovanni Bajo
Post by Eric Botcazou
I've never created/managed branches or tagged anything in the GCC
- time to do a complete check-out on mainline/branch
Check-out is 30% slower because of the time needed to write the duplicate local
copy. On the other hand, there is a nice option "svn switch" which lets you
switch a working copy tree from mainling to any branch and viceversa just by
downloading the delta between the two, so much faster than checking out
- svn co path/to/mainline patch-sparc-frame-pointer (checkout pristine tree
to work on a specific patch)
- Write/test patch on mainline. Review/commit it. Committed as r1234567 (single
number identifies changes to 10 files, 1 rename, 2 deletions).
- From within .path-sparc-frame-pointer directory, svn switch
path/to/gcc40branch (switch to 4.0 branch)
- Backport patch: svn merge -r1234567 /path/to/mainline (automatically
rename, delete, apply modifies).
- Test/commit.
- svn switch path/to/gcc34/branch (switch to 3.4 branch)
- etc.
With SVK you could work with one working copy developing independent
patches like

start a local branch for patch1
$ svk copy //gcc //gcc-patch1
switch your working copy to that
$ svk switch //gcc-patch1
develop, test, whatever. check in the changes to the local branch
$ svk ci
repeat for patches2..N

when submitting one patch to mainline you can either go through
patches or do merges like
switch to HEAD
$ svk switch //gcc
merge from your branch
$ svk smerge //gcc-patch1
push the changes to mainline as one new revision
$ svk push -l
or generate a patch out of the changes instead
$ svk push -P patch-foobar.diff

Please don't take this as exact way to do things, because this is from
the docs only, and obviously I didn't try doing it.

Richard.
Ranjit Mathew
2005-10-20 11:30:53 UTC
Permalink
Giovanni Bajo wrote:
[...]
Post by Giovanni Bajo
Post by Eric Botcazou
- time to do an update on mainline/branch
When updating, cvs/svn first try to find out what needs to be updated (in rough
terms) and then start downloading the updates. The latter part (download) is
obviously the same, as they both download compressed delta over the network.
The former part is many times faster in svn, and takes the same time on
branches or mailine (while CVS was much slower in the branch) You'll find out
that, after you type "svn up", it'll start downloading the first file *much
faster* than it used to do with cvs, especially on a branch.
I think we ought to remember here that there is a local
CVS patch on sources.redhat.com/gcc.gnu.org that makes
updates from mainline far faster than on a branch. I
think it was written by Ian Lance Taylor. (Search the
overseers mailing list for more information.)

Thanks,
Ranjit.

- --
Ranjit Mathew Email: rmathew AT gmail DOT com

Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
François-Xavier Coudert
2005-10-20 11:25:28 UTC
Permalink
Since there is a big brainstorming, I will sum up my opinion here (and
then stop spending time on this issue). From the discussion, it looks
like the switch seems the most important constraint imposed by the switch
is about hardware/software requirements, and I do strongly second this
point.

For example, some of us have to work on machines on which they're not
root. I asked my sysadmin to install subversion, and it was done a month
and a half later (two weeks ago). I know will have to ask him for svk,
then again a newer svn (and perhaps a updated openssh, but that surely
will be refused). And I'd rather not install all that myself, cause users
are on shared disks with quotas.

Another example: ever tried asking the sourceforge compile farm team for
an update? they're still "considering" updating MacOS 10.1. So yes, there
are solutions for some of the issues some of us have, but they all look a
bit complicated.

Well, maybe gcc this discussion would be spared if gcc contributors were
only people supported by their company. But that's not the case.

FX
Richard Guenther
2005-10-20 11:33:24 UTC
Permalink
Post by François-Xavier Coudert
Since there is a big brainstorming, I will sum up my opinion here (and
then stop spending time on this issue). From the discussion, it looks
like the switch seems the most important constraint imposed by the switch
is about hardware/software requirements, and I do strongly second this
point.
For example, some of us have to work on machines on which they're not
root. I asked my sysadmin to install subversion, and it was done a month
and a half later (two weeks ago). I know will have to ask him for svk,
then again a newer svn (and perhaps a updated openssh, but that surely
will be refused). And I'd rather not install all that myself, cause users
are on shared disks with quotas.
Another example: ever tried asking the sourceforge compile farm team for
an update? they're still "considering" updating MacOS 10.1. So yes, there
are solutions for some of the issues some of us have, but they all look a
bit complicated.
Well, maybe gcc this discussion would be spared if gcc contributors were
only people supported by their company. But that's not the case.
All this hassle is why I suggested keeping CVS working in read-only mode.
Going through patches applied by someone else may be less of a hassle
than dealing with above (until two month later you sysadmin installed svn).

Richard.
Richard Kenner
2005-10-20 14:57:15 UTC
Permalink
Sorry about that, but let's not remember of the other dozens which
works on branches and can do a merge in seconds instead of literally
*hours*, and so on.

Yes, but how often do even those who work on branches a lot do merges?
If not very often, why not just start it up, background it, and go to sleep?

I don't think we can uniformly win everywhere, right now. I believe I
have already shown and spoken about many day-to-day advantages even
for people working only on mainline/release branches, and I'm sure
that people that wanted to listen have understood.

What I keep seeing are increasingly complex solutions in order to keep
efficiency the same as it is now. This is a very large distributed cost,
which can't be ignored.
Giovanni Bajo
2005-10-20 14:59:31 UTC
Permalink
Post by Richard Kenner
Sorry about that, but let's not remember of the other dozens which
works on branches and can do a merge in seconds instead of literally
*hours*, and so on.
Yes, but how often do even those who work on branches a lot do merges?
Less often than needed or wanted, because it takes way too much time to do
one, instead of few seconds as it should. One may want to merge a
development branch every day or so, but it can't be done right now because
the overhead of the operation is too high. This causes people to batch
merges in big drops, which increase the conflicts and the time to solve
those (when something does not work, you have to investigate a larger
timespan to find out what broken what, and you have to do that without even
seeing atomic changesets in logs).
Post by Richard Kenner
If not very often, why not just start it up, background it, and go to sleep?
Notice that large merge commits on branches lock the whole CVS repository
for everybody for long time.
--
Giovanni Bajo
Andrew Haley
2005-10-20 15:07:03 UTC
Permalink
Post by Richard Kenner
What I keep seeing are increasingly complex solutions in order to
keep efficiency the same as it is now. This is a very large
distributed cost, which can't be ignored.
No, but neither should the cost be puffed up, as it is being at the
moment. SSH connection caching solves the slow connection problem
with very little setup cost. It's not worth making a fuss about.

Andrew.
Richard Kenner
2005-10-20 14:52:55 UTC
Permalink
I'm going to write something in the wiki about svk. There's much FUD
spreading in this thread. DanJ put up a wiki page on the OpenSSH
configuration (which really could be found with 3 minutes of googling,
which is shorter than writing a mail asking information about it [not
speaking of you, gaby]).

I must say that I find the amount of "fiddling" and special options or
configurations needed here very disturbing. People make a comment and one
of the experts gives an answer of the form "oh, just turn on <yet another
obscure option in some tool>".

This is barely described in a wiki, let alone in any real documentation. And
lots of people don't even like to read documentation. Plus, a huge amount of
hackery will scare people off.

I'm very concerned that we're greating increasing the barrier to entry for
work on GCC. cvs is very intuitive and simple to use. I'm not seeing the
same thing for svn/svk, but instead a series of increasingly complex
suggestions on how to do things efficiently.

Saying "casual developers of GCC can use snapshots" is not something I think
we ought to be doing.
T***@Physik.Uni-Muenchen.DE
2005-10-20 15:13:27 UTC
Permalink
(I'm sorry that I'm breaking threading, but I don't feel to bad about this given
whom I'm replying to, it's not like I'm cutting a huge thread in two)
Post by Richard Kenner
I must say that I find the amount of "fiddling" and special options or
configurations needed here very disturbing. People make a comment and one
of the experts gives an answer of the form "oh, just turn on <yet another
obscure option in some tool>".
This is barely described in a wiki, let alone in any real documentation. And
lots of people don't even like to read documentation. Plus, a huge amount of
hackery will scare people off.
All these options are meant to address specific concerns people are having, they
are not required to use svn effectively. ssh multiplexing in particular applies
equally well to cvs as well.
Post by Richard Kenner
I'm very concerned that we're greating increasing the barrier to entry for
work on GCC. cvs is very intuitive and simple to use. I'm not seeing the
same thing for svn/svk, but instead a series of increasingly complex
suggestions on how to do things efficiently.
If you don't want to do things more effectively than in cvs (svn merge comes to
mind) there really is no great difference in using svn. Tags, branches and
revisions are in my opinion _much_ easier to understand in svn. How many
people really understand how cvs version numbers come about, when stuff ends up
in the attic etc (I remember this question appearing on fortran@ just last
week); how again do you figure out the set of files changed in a single cvs
commit (you don't, you search through the gcc-cvs archives) etc. svn _is_
easier, and it's not difficult to install, as the downloadable source tarball
is self-contained (or "reasonably self-contained", it required no additional
downloads for building on the rather barebones setup my institute is using)
Post by Richard Kenner
Saying "casual developers of GCC can use snapshots" is not something I think
we ought to be doing.
I don't think so either.

Since a lot of people have expressed concerns WRT to the switch, I'd like to say
that I'm all in favor of switching, and I think that I'm speaking for a
not-so-vocal majority. I've had to wait for a lock too often, and working on
branches (esp backporting patches) has cost too much of time for me to be a fan
of staying with cvs. The increased disk usage will be compensated for by the
easy means of switching a checked-out tree between branches. The only issue
I'm having is that there seems to be no way of excluding certain directories in
a checkout, e.g. I have zero interest in Ada, yet it takes up a lot of diskspace
(and no, 'svn co -N' is no alternative).

Finally, the move to subversion was agreed to in February, the increased disk
usage was discussed then, and a test repository was setup back then. I found a
few issues (svn ann ChangeLog comes to mind) which I made sure Daniel Berlin
knew about, and the next released version of subversion contained fixes for
them. It completely escapes me why so many people didn't deem it necessary to
give it a spin back then, especially given the fact that Daniel Berlin
committed to fixing any issues that came up in the testing. Even now very few
people have actually tried working with svn -- the repository revision has
increased by less than ten revisions since I originally checked out the tree a
few days ago.

- Tobi

(Disclaimer: I've been using svn a little before the test repository was set up,
but only on very small projects, nevertheless I heavily used tags there simply
because it was so easy compared to cvs)
Richard Kenner
2005-10-20 15:29:33 UTC
Permalink
Less often than needed or wanted, because it takes way too much time
to do one, instead of few seconds as it should. One may want to merge
a development branch every day or so, but it can't be done right now
because the overhead of the operation is too high. This causes people
to batch merges in big drops, which increase the conflicts and the
time to solve those (when something does not work, you have to
investigate a larger timespan to find out what broken what, and you
have to do that without even seeing atomic changesets in logs).

Is the actual time of doing the merge itself the dominating factor?
Even if it were done every day, I'd expect some conflicts and things
not working. You certainly have to include testing time in the merge
time. I'm skeptical that the actual merge rate of branches would
increase much.

Notice that large merge commits on branches lock the whole CVS
repository for everybody for long time.

That is indeed an issue.
Continue reading on narkive:
Loading...