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 Fri, 2005-10-21 at 09:29 +0200, Lars Gullik Bjønnes wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | 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 una
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 authe
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 l
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
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.
> |
>
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 met
Daniel Berlin <[EMAIL PROTECTED]> writes:
| 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
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 no
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?
(AFA
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* yo
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 p
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. Name
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 fiv
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
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 gre
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
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
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
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?
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
On Oct 20, 2005, at 2:45 AM, 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.
I'm on darwin, grabbed tarball, built
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 workin
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
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
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
> docu
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,
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.
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 ...
> 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,
On Thu, Oct 20, 2005 at 07:46:52AM -0700, Mark Mitchell wrote:
> 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,
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 com
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 la
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 probl
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
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
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 compi
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 no
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 m
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 bee
On Thursday 20 October 2005 15:33, Daniel Jacobowitz wrote:
> I eagerly look forward to svn.
Yay. Agreed.
Gr.
Steven
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 te
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 ca
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
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
t
(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)
Richard Kenner wrote:
> I must say that I find the amount of "fiddling" and special options or
> configurations needed here very disturbing. Peop
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 cach
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
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,
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
spe
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 no
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 acc
Daniel Jacobowitz <[EMAIL PROTECTED]> 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
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
> 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
On Thu, 2005-10-20 at 14:09 +0200, Gabriel Dos Reis wrote:
> "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 tha
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, wi
"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
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
dis
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
| 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 examp
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 improv
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 muc
"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
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 har
-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
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 e
-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
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,
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 t
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% slowe
> 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
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 depend
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 t
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
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, s
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 t
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 techni
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 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
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 almo
> Irrespective of the other issues currently discussed, this is a very
> good idea!
Seconded!
--
Eric Botcazou
> > 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 rig
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 wit
> 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 no
-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
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
> | >
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
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
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
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 appare
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
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 respoist
Joe Buck wrote:
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
Richard Kenner <[EMAIL PROTECTED]> wrote:
> 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 th
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
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 wor
Diego Novillo wrote:
> On Wednesday 19 October 2005 14:36, Daniel Berlin wrote:
>
>
>>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
On Wednesday 19 October 2005 14:36, Daniel Berlin wrote:
> 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'.
Daniel Berlin 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 spen
1 - 100 of 140 matches
Mail list logo
