On Thu, 20 Oct 2005, Richard Guenther wrote:
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.
That would be great. It would allow me to continue my nightly bootstraps
on some guest account without interruption.
On
On 2005-10-21 09:29:24 +0200, Lars Gullik Bjønnes wrote:
mmm... so when using plain svn: then thre is only one connection? or
is five connections made then too?
5 connections too, but each connection should be much faster
(almost immediate). The number of connections does not depend
on the
Lars Gullik Bjønnes writes:
Bernd Schmidt [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| It seems that svn is unable to send all its requests to the svn
| repo over one ssh connection. In one test I just did I had to enter
| the ssh password five times.
|
| man
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
On 19 Oct 2005, Giovanni Bajo yowled:
Andreas Schwab [EMAIL PROTECTED] wrote:
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
On Thu, 20 Oct 2005, Daniel Berlin wrote:
1.4 should have svn and SSL support, in a way that will allow us to not
have to pay the ssl handshake peanlty except during things requiring
auth. When this comes along, we will move to it, which will probably
require some sort of underlying
Arnaud Charlet [EMAIL PROTECTED] 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
Daniel Berlin [EMAIL PROTECTED] 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
Joe Buck [EMAIL PROTECTED] 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
Daniel Berlin [EMAIL PROTECTED] 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
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
On 20 Oct 2005 08:58:36 +0200, Gabriel Dos Reis
[EMAIL PROTECTED] wrote:
Joe Buck [EMAIL PROTECTED] 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arnaud Charlet wrote:
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
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
Richard Guenther wrote:
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
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
Irrespective of the other issues currently discussed, this is a very
good idea!
Seconded!
--
Eric Botcazou
On Thu, 2005-10-20 at 09:58, Arnaud Charlet wrote:
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
On Thu, 20 Oct 2005, Richard Guenther wrote:
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
On Oct 20, 2005 11:01 AM, Eric Botcazou [EMAIL PROTECTED]
wrote:
- portability of svn to non-Linux systems
http://subversion.tigris.org/faq.html#portability
Gr.
Steven
On 10/20/05, Joseph S. Myers [EMAIL PROTECTED] wrote:
On Thu, 20 Oct 2005, Richard Guenther wrote:
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
Eric Botcazou [EMAIL PROTECTED] wrote:
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
Check-out is 30% slower because of the time needed to write the duplicate local
copy. On the
A few comments, since your message makes it sound like everything is
better, which is not true in reality.
- 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
Gabriel Dos Reis [EMAIL PROTECTED] wrote:
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
Giovanni Bajo writes:
Gabriel Dos Reis [EMAIL PROTECTED] wrote:
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.
Arnaud Charlet [EMAIL PROTECTED] wrote:
- 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
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
On 10/20/05, Giovanni Bajo [EMAIL PROTECTED] wrote:
Eric Botcazou [EMAIL PROTECTED] wrote:
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
Check-out is 30% slower because of
On 2005-10-20, at 11:45, Arnaud Charlet wrote:
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
On Oct 20, 2005 12:11 PM, Arnaud Charlet [EMAIL PROTECTED] wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arnaud Charlet wrote:
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Giovanni Bajo wrote:
[...]
- 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
On 10/20/05, François-Xavier Coudert [EMAIL PROTECTED] wrote:
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
Giovanni Bajo [EMAIL PROTECTED] 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
On Thu, 2005-10-20 at 11:51 +0200, Giovanni Bajo wrote:
Gabriel Dos Reis [EMAIL PROTECTED] wrote:
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
On Thu, 2005-10-20 at 12:11 +0200, Arnaud Charlet wrote:
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
| 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
Gabriel Dos Reis [EMAIL PROTECTED] wrote:
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
Daniel Berlin [EMAIL PROTECTED] 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
Giovanni Bajo [EMAIL PROTECTED] 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
On Thu, Oct 20, 2005 at 12:11:20PM +0200, Arnaud Charlet wrote:
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
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.
Daniel Berlin [EMAIL PROTECTED] 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
Daniel Berlin wrote:
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
Joseph S. Myers wrote:
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
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
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
Richard Kenner [EMAIL PROTECTED] wrote:
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
Richard Kenner writes:
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
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
Richard Guenther [EMAIL PROTECTED] writes:
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
On Thu, 2005-10-20 at 09:39 -0500, Bobby McN wrote:
Daniel Berlin wrote:
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
On Thu, 2005-10-20 at 08:52 -0700, Ian Lance Taylor wrote:
Richard Guenther [EMAIL PROTECTED] writes:
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
On Thursday 20 October 2005 15:33, Daniel Jacobowitz wrote:
I eagerly look forward to svn.
Yay. Agreed.
Gr.
Steven
On Oct 20, 2005, Daniel Berlin [EMAIL PROTECTED] wrote:
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.
And then, cvs diff -r1 -r2 also requires a ssh handshake, so I don't
get what it is that people have been
On Thursday 20 October 2005 16:57, Richard Kenner wrote:
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
On 2005-10-20, at 16:57, Richard Kenner wrote:
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
On Thu, Oct 20, 2005 at 12:20:17PM -0400, Daniel Berlin wrote:
On Thu, 2005-10-20 at 09:39 -0500, Bobby McN wrote:
Daniel Berlin wrote:
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
On Oct 20, 2005, [EMAIL PROTECTED] (Richard Kenner) wrote:
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.
The same can be said of svn, so it's not like a great barrier increase.
I'm not seeing the same thing
Gabriel Dos Reis [EMAIL PROTECTED] wrote:
I'm looking forward to solutions that lower the entry barrier,
specifically with repect too OpenSSH, diff and svk.
On Thu, Oct 20, 2005 at 11:51:28AM +0200, Giovanni Bajo wrote:
I'm going to write something in the wiki about svk. There's much FUD
On Thu, Oct 20, 2005 at 08:42:25AM -0400, Daniel Berlin wrote:
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.
It always works that way. The problem
On Thu, 2005-10-20 at 10:04 -0700, Joe Buck wrote:
Gabriel Dos Reis [EMAIL PROTECTED] wrote:
I'm looking forward to solutions that lower the entry barrier,
specifically with repect too OpenSSH, diff and svk.
I think we should try to optimize the read-only access case, since large
On Thu, Oct 20, 2005 at 03:12:30PM +0200, Gabriel Dos Reis wrote:
Daniel Berlin [EMAIL PROTECTED] 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.
What I keep seeing are increasingly complex solutions in order to keep
efficiency the same as it is now.
Ah, come on. That just takes some getting used to.
In *some* cases, indeed I'm seeing do it this way instead of that way where
the suggested way isn't more complicated,
Ideally, once this discussion is over, some kind subversion expert will
update the wiki to contain the answers to the questions raised on this
thread.
Ideally once this discussion is over, the information will be in real
documentation, not just the wiki ...
Make that *more* efficiently. AFAIK svn is much more efficient than
cvs by default in all cases, except for disk space use.
Arno's numbers seem to disagree with you there.
Joe Buck wrote:
Another possibility is to increase the frequency of snapshots after
the switch to subversion. They will have a lower cost, since it will
no longer be necessary to lock the database for an hour to attach the
snapshot tag. Or maybe no tag is necessary at all for snapshots,
if
On Thursday 20 October 2005 18:34, Richard Kenner wrote:
Ideally, once this discussion is over, some kind subversion expert
will update the wiki to contain the answers to the questions raised on this
thread.
Ideally once this discussion is over, the information will be in real
There already IS real documentation, and it's very good.
http://svnbook.red-bean.com/
The online help provided by svn help is also very good as a quick
reference.
No, I don't mean documentation of svn (I assumed it had a manual ...),
I mean a replacement for the information
Joe Buck [EMAIL PROTECTED] writes:
| On Thu, Oct 20, 2005 at 03:12:30PM +0200, Gabriel Dos Reis wrote:
| Daniel Berlin [EMAIL PROTECTED] writes:
|
| [...]
|
| | I have absolutely no reason to expect the feedback process to change if
| | we waited. I have absolutely no reason to believe
Ian Lance Taylor wrote:
Richard Guenther [EMAIL PROTECTED] writes:
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
Kevin Handy [EMAIL PROTECTED] writes:
Would it be possible to write a cvs read-only interface to the
svn database? i.e. replace the cvs server with a svn-cvs emulation
layer.
In principle, sure, why not? The CVS client server protocol is well
documented.
In practice sounds like quite a bit
There already IS real documentation, and it's very good.
http://svnbook.red-bean.com/
Actually, I just went to that site and the latest printable (i.e., PDF)
version I can find there is for version 1.1. Is that going to be good enough?
Daniel Berlin [EMAIL PROTECTED] writes:
| 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
On Thu, Oct 20, 2005 at 06:15:38PM -0400, Richard Kenner wrote:
There already IS real documentation, and it's very good.
http://svnbook.red-bean.com/
Actually, I just went to that site and the latest printable (i.e., PDF)
version I can find there is for version 1.1. Is that
Alexandre Oliva [EMAIL PROTECTED] writes:
| On Oct 20, 2005, Daniel Berlin [EMAIL PROTECTED] wrote:
|
| 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.
|
| And then, cvs diff -r1 -r2 also requires a ssh
Alexandre Oliva [EMAIL PROTECTED] writes:
On Oct 20, 2005, [EMAIL PROTECTED] (Richard Kenner) wrote:
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.
The same can be said of svn, so it's not like a great
Lars Gullik Bjønnes wrote:
It seems that svn is unable to send all its requests to the svn
repo over one ssh connection. In one test I just did I had to enter
the ssh password five times.
man ssh-agent
Bernd
Bernd Schmidt [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| It seems that svn is unable to send all its requests to the svn
| repo over one ssh connection. In one test I just did I had to enter
| the ssh password five times.
|
| man ssh-agent
The connection is still set up five
Lars Gullik Bj=F8nnes wrote:
It seems that svn is unable to send all its requests to the svn
repo over one ssh connection. In one test I just did I had to enter
the ssh password five times.
man ssh-agent
You're missing the point: he's making an efficiency argument.
On Fri, 2005-10-21 at 02:19 +0200, Lars Gullik Bjønnes wrote:
Bernd Schmidt [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| It seems that svn is unable to send all its requests to the svn
| repo over one ssh connection. In one test I just did I had to enter
| the ssh password
There have been no answers on the following point...
On 2005-10-19 16:44:59 +0200, Arnaud Charlet wrote:
$ 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).
These are the last two revs *up to* your
On 2005-10-19 17:12:32 +0200, Arnaud Charlet wrote:
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.
For those without OpenSSH = 4.0, can't fsh be a solution?
(AFAIK,
On 2005-10-20 14:46:36 +0200, Paolo Bonzini wrote:
I agree. For example, Fink on the Mac only has svn 1.1 (not that this
is a showstopper IMHO),
FYI, DarwinPorts currently has svn 1.2.3, which can be installed
very easily.
and Debian testing is stuck with the latest 3.8 openssh.
Why not
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
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.
On 10/19/05, Paolo Bonzini [EMAIL PROTECTED] wrote:
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
On Wed, 2005-10-19 at 09:42 -0400, Daniel Berlin wrote:
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.
On Wed, 2005-10-19 at 15:54 +0200, Paolo Bonzini wrote:
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
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
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
Oh I forgot: tied a couple of svn commit operations, which,
after having set the EDITOR env variable, went fine, no troubles.
Arno
On 10/19/05, Arnaud Charlet [EMAIL PROTECTED] wrote:
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
Richard Guenther wrote:
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... ;)
Thanks for your reply and suggestion.
A couple of questions, comments below:
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.
Arnaud Charlet writes:
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
On Wed, 2005-10-19 at 16:44 +0200, Arnaud Charlet wrote:
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
Daniel Berlin [EMAIL PROTECTED] writes:
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
Daniel Berlin wrote:
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
1 - 100 of 131 matches
Mail list logo
