Re: A couple more subversion notes

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

Re: A couple more subversion notes

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

Re: A couple more subversion notes

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

Re: RFC: future gfortran development and subversion

On Wed, 2005-10-19 at 19:43 -0700, Kean Johnston wrote: > > I saw no postings that contained anything like a design for doing this, > > etc, to the dev list from you. > http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=106243 > Oh that one, i'm sorry, i confused your thread with anothe

Re: RFC: future gfortran development and subversion

I saw no postings that contained anything like a design for doing this, etc, to the dev list from you. http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=106243 Of course, you seem represent this thread you started as having actually involved any subversion developers, which it didn't

Re: RFC: future gfortran development and subversion

On Wed, 2005-10-19 at 16:55 -0700, Kean Johnston wrote: > >>I fear the impending switch to subversion will have a negative impact on > >>the future development of gfortran due the rather limited number of people > >>who actually supply patches and the sudden increase in hardware > >>requirements.

Re: A couple more subversion notes

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

Re: RFC: future gfortran development and subversion

I fear the impending switch to subversion will have a negative impact on the future development of gfortran due the rather limited number of people who actually supply patches and the sudden increase in hardware requirements. For example, I find troutmask:sgk[204] du -sh gcc40 gcc41 trunk 241

Re: RFC: future gfortran development and subversion

On Wed, Oct 19, 2005 at 05:06:40PM -0400, Andrew Pinski wrote: > GCC and gfortran (and gcj) should all play by the normal rules that we > made to GCC so that we don't spend too much time backporting (and > looking backwards) instead of fixing bugs. gfortran is the replacement for g77, and it still

Re: Is gcc optimized for thread level parallelism?

On Wed, Oct 19, 2005 at 10:35:29PM +, x z wrote: > Is gcc optimized for thread level parallelism, in view of the recent > development of SMT and multicore architectures? No. > And does gcc support any NUMA (non-uniform memory access) machines? That > is, does gcc > a) automatically paral

Is gcc optimized for thread level parallelism?

Is gcc optimized for thread level parallelism, in view of the recent development of SMT and multicore architectures? Does gcc look for thread level parallelism given a single threaded program (that is, when the programmer does not parallelize the program using pthread etc.)? And does gcc suppor

Re: RFC: future gfortran development and subversion

On Wed, Oct 19, 2005 at 03:36:08PM -0400, Daniel Berlin wrote: > On Wed, 2005-10-19 at 12:16 -0700, Steve Kargl wrote: > > On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote: > > > OK, I'll go read about svk. I scanned the svn docs for an > > --exclude-dir= option or .svnrc file wher

Re: RFC: future gfortran development and subversion

On Wed, Oct 19, 2005 at 10:06:44PM +0200, Richard Guenther wrote: > Dude, I hope fortran will, after branching of 4.1, follow the usual rules > of regression fixes only. Currently, gfortran is in a half-usable state. It is not yet ready as a replacement for g77 (see PR 19292) and there are quite

Re: RFC: future gfortran development and subversion

On Oct 19, 2005, at 4:36 PM, FX Coudert wrote: A regression is a bug that was not in release N - M and was discovered in release N. You are then free to fix N - M + 1 to N. Like you have a testcase that crashes gfortran on 4.1.0, but did not on 4.0.2. But then, you'll explain people that th

Re: A couple more subversion notes

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

Re: Making a new cross-compile target: where to begin?

On 10/20/05, DJ Delorie <[EMAIL PROTECTED]> wrote: > > > Maybe a good place to get clues is to look at how GCC and binutils are > > built for DOS, e.g. DJGPP. (I've asked DJ for some help). > > Except that DJGPP uses COFF, not a.out. DJGPP v1 used a.out, but most > of that support has been remove

Re: RFC: future gfortran development and subversion

FX, The fortran patches are always fortran-contained, and I think if the community thinks it worth to have a different development model (until some point in the future, defined in advance) why shouldn't it be so? This might well be the value of keeping the binaries going. From what I can

Re: Making a new cross-compile target: where to begin?

> Maybe a good place to get clues is to look at how GCC and binutils are > built for DOS, e.g. DJGPP. (I've asked DJ for some help). Except that DJGPP uses COFF, not a.out. DJGPP v1 used a.out, but most of that support has been removed by now.

Re: Making a new cross-compile target: where to begin?

> Well, as far as I have seen, most of the internals are documented in the > code itself. The best way to learn how it works, in my opinion, is to get > a good code cross-reference tool. The files you mostly want to look at are > in gcc/config in a build tree. > > Good luck and have fun, > Jonathan

Re: RFC: future gfortran development and subversion

A regression is a bug that was not in release N - M and was discovered in release N. You are then free to fix N - M + 1 to N. Like you have a testcase that crashes gfortran on 4.1.0, but did not on 4.0.2. But then, you'll explain people that they won't have a decent fortran compiler in distro

Re: RFC: future gfortran development and subversion

On 10/19/05, Steve Kargl <[EMAIL PROTECTED]> wrote: > On Wed, Oct 19, 2005 at 10:06:44PM +0200, Richard Guenther wrote: > > On 10/19/05, Tobias Schl?ter <[EMAIL PROTECTED]> wrote: > > > Steve Kargl wrote: > > > > Now, to my proposal for future gfortran development post 4.1 branching. > > > > When (

Re: A couple more subversion notes

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

Re: RFC: future gfortran development and subversion

On Wed, Oct 19, 2005 at 10:06:44PM +0200, Richard Guenther wrote: > On 10/19/05, Tobias Schl?ter <[EMAIL PROTECTED]> wrote: > > Steve Kargl wrote: > > > Now, to my proposal for future gfortran development post 4.1 branching. > > > When (if) svn becomes the source code revision tool, I propose that

Re: RFC: future gfortran development and subversion

On 10/19/05, Tobias Schlüter <[EMAIL PROTECTED]> wrote: > > [ I've added gcc@ to the CC list and reproduced the message in full, FX > already got the "buy a bigger harddisk" answer there, I think it makes sense > to show that other people care about this, too ] > > Steve Kargl wrote: > > Now, to my

Re: A couple more subversion notes

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: RFC: future gfortran development and subversion

On Wed, 2005-10-19 at 12:16 -0700, Steve Kargl wrote: > On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote: > OK, I'll go read about svk. I scanned the svn docs for an > --exclude-dir= option or .svnrc file where excluding directories > could be done. So far, I've come up empty. I

Re: A couple more subversion notes

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

Re: RFC: future gfortran development and subversion

Steve Kargl wrote: > On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote: > >>>694Msvn40 <-- svn 4.0 branch 694Msvn41 <-- svn 4.1 branch 694M >>>trunk <-- svn mainline >>> >>>Now add one or two additional svn directories for large change sets and >>>this becomes intolerab

Re: A couple more subversion notes

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

Re: RFC: future gfortran development and subversion

On Wed, Oct 19, 2005 at 08:59:36PM +0200, Tobias Schl?ter wrote: > > > > 694Msvn40 <-- svn 4.0 branch 694Msvn41 <-- svn 4.1 branch 694M > > trunk <-- svn mainline > > > > Now add one or two additional svn directories for large change sets and > > this becomes intolerable. (Before a

Re: RFC: future gfortran development and subversion

[ I've added gcc@ to the CC list and reproduced the message in full, FX already got the "buy a bigger harddisk" answer there, I think it makes sense to show that other people care about this, too ] Steve Kargl wrote: > I fear the impending switch to subversion will have a negative impact on > the

Re: A couple more subversion notes

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'.

Re: A couple more subversion notes

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

Re: A couple more subversion notes

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? > > FWIW my personal opinion, indeed are enough from me (in particular, some time ago, I have been discussing the diff preparation thing with Matt

Re: A couple more subversion notes

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

The move to subversion

Daniel, As a long-time user of CVS (before it was a binary ;-) that recently read the "Turtle book" and as a long-time user of the open gcc source tree (although less so recently), I am very happy with the proposed move to svn. Thank you and all the svn developers for all your hard work to make i

Re: using multiple trees with subversion

On Oct 19, 2005, at 2:56 AM, François-Xavier Coudert wrote: Or am I the only person to find that disk is expensive (or working on his own hardware, maybe)? A checkout costs US$0.50. This is around 2.6x more expensive than a cvs checkout. Check around locally, maybe you can find `throwaways

Re: Making a new cross-compile target: where to begin?

[EMAIL PROTECTED] said: > Hi, > > I know that some people are working on a GCC port for Minix v3, but > I'd like to work on a cross-compiler for my own purposes. I'd like > the host and build to be i686-pc-linux-gnu, and the target to be > i[3456]86-pc-minix3. > > Can anyone give me some advice on

Re: A couple more subversion notes

"Giovanni Bajo" <[EMAIL PROTECTED]> writes: > Ah, maybe it's a later fix? I'm using: > > $ ssh -V > OpenSSH_4.2p1, OpenSSL 0.9.7f 22 Mar 2005 Maybe, I'm using 4.1p1. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key

Making a new cross-compile target: where to begin?

Hi, I know that some people are working on a GCC port for Minix v3, but I'd like to work on a cross-compiler for my own purposes. I'd like the host and build to be i686-pc-linux-gnu, and the target to be i[3456]86-pc-minix3. Can anyone give me some advice on where to begin and what info I need?

Re: A couple more subversion notes

On Wed, Oct 19, 2005 at 05:26:42PM +0200, Andreas Schwab wrote: > "Giovanni Bajo" <[EMAIL PROTECTED]> writes: > > > 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 wh

Re: A couple more subversion notes

On Wed, 2005-10-19 at 17:06 +0200, Paolo Carlini wrote: > 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

Re: A couple more subversion notes

Giovanni Bajo wrote: >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

Re: A couple more subversion notes

Arnaud Charlet <[EMAIL PROTECTED]> wrote: > 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

Re: A couple more subversion notes

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 using: $ ssh -V OpenSSH_4.2p1, OpenSS

Re: A couple more subversion notes

Steven Bosscher <[EMAIL PROTECTED]> wrote: >> 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 >>

Re: A couple more subversion notes

"Giovanni Bajo" <[EMAIL PROTECTED]> writes: > 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. > If I remove the socket file, i

Re: A couple more subversion notes

On Wed, 2005-10-19 at 11:15 -0400, Daniel Jacobowitz wrote: > On Wed, Oct 19, 2005 at 05:12:32PM +0200, Arnaud Charlet wrote: > > > 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. > > > > >

Re: A couple more subversion notes

Andrew Haley <[EMAIL PROTECTED]> wrote: > 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. > [EMAIL PROTECTED] gcc-head-test]$ svn status --verbose Ch

Re: A couple more subversion notes

On Wed, Oct 19, 2005 at 05:18:26PM +0200, Richard Guenther wrote: > On 10/19/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > > On Wed, Oct 19, 2005 at 05:12:32PM +0200, Arnaud Charlet wrote: > > > > Most of this is ssh overhead, because your diff is so small. > > > > > > I disagree, the diff isn

Re: A couple more subversion notes

On Wed, Oct 19, 2005 at 05:17:32PM +0200, Arnaud Charlet wrote: > 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

Re: A couple more subversion notes

Daniel Berlin writes: > > > 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 so

Re: A couple more subversion notes

On Wed, 2005-10-19 at 17:12 +0200, Arnaud Charlet wrote: > > 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 compr

Re: A couple more subversion notes

On 10/19/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Wed, Oct 19, 2005 at 05:12:32PM +0200, Arnaud Charlet wrote: > > > 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

Re: A couple more subversion notes

> 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). > 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

Re: A couple more subversion notes

On Wed, Oct 19, 2005 at 05:03:03PM +0200, Andreas Schwab wrote: > 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 tel

Re: A couple more subversion notes

On Wed, Oct 19, 2005 at 05:12:32PM +0200, Arnaud Charlet wrote: > > 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. > > T

Re: A couple more subversion notes

> 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 canno

Re: A couple more subversion notes

> 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 repos

Re: A couple more subversion notes

On Wednesday 19 October 2005 17:06, Paolo Carlini wrote: > 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 (o

Re: A couple more subversion notes

Andreas Schwab <[EMAIL PROTECTED]> wrote: >> 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

Re: A couple more subversion notes

Arnaud Charlet <[EMAIL PROTECTED]> wrote: > 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-

Re: A couple more subversion notes

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 sil

Re: A couple more subversion notes

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 th

Re: A couple more subversion notes

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 han

Re: A couple more subversion notes

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. > > - firs

Re: A couple more subversion notes

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 tre

Re: using multiple trees with subversion

On 2005-10-19 13:48:36 +0200, Giovanni Bajo wrote: > Probably you're the only one finding disk space expensive. One can also write data on memory cards and they are expensive. This would be important to use Subversion on a PDA. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web:

Re: A couple more subversion notes

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... ;

Re: A couple more subversion notes

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 handle

Re: A couple more subversion notes

Oh I forgot: tied a couple of svn commit operations, which, after having set the EDITOR env variable, went fine, no troubles. Arno

Re: A couple more subversion notes

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/s

Re: A couple more subversion notes

> 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 p

Re: A couple more subversion notes

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

Re: A couple more subversion notes

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.

Re: using multiple trees with subversion

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giovanni Bajo wrote: > > Probably you're the only one finding disk space expensive. HDs are quite > cheap nowadays. Anyway, I'm sure SVN people would be happy if you help Well, I'm another person who's concerned about growing local copy sizes. As it

Re: A couple more subversion notes

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

Re: using multiple trees with subversion

Having 5 subversion trees will need much more space (for local pristine copies), which I don't really have. Is there any way to force subversion use one pristine tree for all modified trees, or is my way of handling things completely rotten? I have a script called svn-switch-patch that undoes

Re: A couple more subversion notes

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.

A couple more subversion notes

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 hi

Deinitialization of globals

I need to enforce a certain initialization and deinitialization order of static variables in GCC, even between different translation units. There is an extension called init_priority, which initializes my variable first, but its deinitialization order is weird: 8<--

Re: using multiple trees with subversion

On Wed, 2005-10-19 at 08:14 -0400, Daniel Berlin wrote: > On Wed, 2005-10-19 at 11:56 +0200, François-Xavier Coudert wrote: > > > Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably > > > have > > > support for checking out repositories with compressed local copies (or no > >

Re: using multiple trees with subversion

On Wed, 2005-10-19 at 11:56 +0200, François-Xavier Coudert wrote: > > Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably have > > support for checking out repositories with compressed local copies (or no > > copy > > at all -- but I wouldn't suggest this, as you'd start to be

Re: using multiple trees with subversion

On Wed, 2005-10-19 at 13:48 +0200, Giovanni Bajo wrote: > François-Xavier Coudert <[EMAIL PROTECTED]> wrote: > > >> Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably > >> have support for checking out repositories with compressed local copies > >> (or no copy at all -- but I

Re: using multiple trees with subversion

François-Xavier Coudert <[EMAIL PROTECTED]> wrote: >> Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably >> have support for checking out repositories with compressed local copies >> (or no copy at all -- but I wouldn't suggest this, as you'd start to be >> slow in "svn diff",

Re: using multiple trees with subversion

> Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably have > support for checking out repositories with compressed local copies (or no copy > at all -- but I wouldn't suggest this, as you'd start to be slow in "svn > diff", > "svn stat", etc). I guess no local copy would be fi

Re: using multiple trees with subversion

François-Xavier Coudert <[EMAIL PROTECTED]> wrote: > I do only have small involvement in gcc, preparing few patches (never > more than 5 at a time) on limited areas (gcc/fortran, libgfortran and > gcc/testsuite), always on mainline or 4.0 branch. The way I manage to > keep mind sanity right now is

Re: using multiple trees with subversion

* François-Xavier Coudert: > Having 5 subversion trees will need much more space (for local > pristine copies), which I don't really have. Is there any way to force > subversion use one pristine tree for all modified trees, or is my way > of handling things completely rotten? You could try svk, i

using multiple trees with subversion

Hi all, I've been playing with the svn test repo during the last few days, updating my own (few) scripts and all, and it's been going very smoothly. The only thing that's worrying me is disk usage. I do only have small involvement in gcc, preparing few patches (never more than 5 at a time) on lim