* Daniel Berlin:
> It's not easier to implement. Trying to translate cvs into changesets
> is not easy (though the reverse is), unless you do it the stupid way (IE
> not try to discover what is a copy and what isn't).
> So matching commit for commit won't give you good history.
> Especially on br
On Tue, 2005-02-15 at 00:55 +0100, Marcin Dalecki wrote:
> On 2005-02-14, at 19:47, Mike Stump wrote:
>
> > On Monday, February 14, 2005, at 04:04 AM, Richard Earnshaw wrote:
> >>> Fine, i'll just keep all the non-snapshot tags for now.
> >>
> >> There's no reason why we have to keep all the tags
On 2005-02-14, at 19:47, Mike Stump wrote:
On Monday, February 14, 2005, at 04:04 AM, Richard Earnshaw wrote:
Fine, i'll just keep all the non-snapshot tags for now.
There's no reason why we have to keep all the tags in one place.
Further, we can import them all, and then later remove, move or ren
On Mon, 2005-02-14 at 15:20 -0800, Geoffrey Keating wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> > I also plan on excluding merge tags
>
> I'd really rather that you didn't. Those tags are useful when you're
> looking at some old change on a branch.
I meant for the test repo.
However,
Daniel Berlin <[EMAIL PROTECTED]> writes:
> I also plan on excluding merge tags
I'd really rather that you didn't. Those tags are useful when you're
looking at some old change on a branch.
On Mon, 2005-02-14 at 10:47 -0800, Mike Stump wrote:
> On Monday, February 14, 2005, at 04:04 AM, Richard Earnshaw wrote:
> >> Fine, i'll just keep all the non-snapshot tags for now.
> >
> > There's no reason why we have to keep all the tags in one place.
>
> Further, we can import them all, and
On Monday, February 14, 2005, at 04:04 AM, Richard Earnshaw wrote:
Fine, i'll just keep all the non-snapshot tags for now.
There's no reason why we have to keep all the tags in one place.
Further, we can import them all, and then later remove, move or rename
them and these things seem to be versi
On Sat, 2005-02-12 at 02:53, Daniel Berlin wrote:
> On Fri, 2005-02-11 at 18:40 -0800, Mike Stump wrote:
> > On Friday, February 11, 2005, at 05:29 PM, Daniel Berlin wrote:
> > > I'll keep the last branchpoint of each branch for the initial import
> >
> > Won't work either... Sometimes we reuses
[EMAIL PROTECTED] (Paul Schlie) wrote on 11.02.05 in <[EMAIL PROTECTED]>:
> - I apparently misinterpreted:
>
> http://svn.collab.net/viewcvs/svn/trunk/
>
> as was viewing it via viewcvs (which I now understand is svn friendly)
In general, these days, /viewcvs/cvs/... will access a CVS reposi
> Right - using svn programs to directly modify the svk depot (which is it's
> local 'repository'), is touchy. You *can* do it, but you have to be quite
> careful about the svk:* properties used to track merges and mirrors.
> Generally there's no need, other than perhaps using a read-only client t
On Fri, 2005-02-11 at 17:38 -0800, Zack Weinberg wrote:
> On Fri, 2005-02-11 at 20:29 -0500, Daniel Berlin wrote:
> > On Fri, 2005-02-11 at 20:25 -0500, Nathanael Nerode wrote:
> > > (For a new, all-svn branch, there are easier ways of keeping track of that
> > > revision number, like putting it in
On Fri, 2005-02-11 at 20:29 -0500, Daniel Berlin wrote:
> On Fri, 2005-02-11 at 20:25 -0500, Nathanael Nerode wrote:
> > (For a new, all-svn branch, there are easier ways of keeping track of that
> > revision number, like putting it in the log message for the merge.)
>
> Or using svnmerge, which d
First of all, I totally approve of moving to Subversion.
Daniel Berlin wrote:
>I also plan on excluding merge tags
It's not safe to exclude the most recent mergepoint tag for
a live branch. We will lose necessary information for the next
merge to that branch.
You wrote elsewhere:
>Find the curr
Daniel Berlin wrote:
On Fri, 2005-02-11 at 12:08 -0500, Daniel Jacobowitz wrote:
On Fri, Feb 11, 2005 at 12:00:26PM -0500, Daniel Berlin wrote:
Because if it's a show stopper, then so will be arch, monotone, or any
of our other replacements (they all either store the entire repo on your
disk, or
On Fri, 2005-02-11 at 20:25 -0500, Nathanael Nerode wrote:
> First of all, I totally approve of moving to Subversion.
>
> Daniel Berlin wrote:
> >I also plan on excluding merge tags
>
> It's not safe to exclude the most recent mergepoint tag for
> a live branch. We will lose necessary informatio
Daniel Berlin wrote:
On Fri, 2005-02-11 at 17:13 +, Joern RENNECKE wrote:
Joseph S. Myers wrote:
You mean the revision number of the whole checked out tree, which the
"svnversion" utility will tell you in any checked out svn tree (including
whether the tree is modified or mixed version). Giv
On Fri, 2005-02-11 at 18:40 -0800, Mike Stump wrote:
> On Friday, February 11, 2005, at 05:29 PM, Daniel Berlin wrote:
> > I'll keep the last branchpoint of each branch for the initial import
>
> Won't work either... Sometimes we reuses merge labels in non-obvious
> ways. top-200501-merge and
Daniel Berlin wrote:
>
>> >
>> > You can't mix svn and svk commits against the same repo. It confuses
>> > svk (not svn).
>> >
>> > You can use svk readonly, of course.
>>
>> Actually, that's not quite right. While svk's depot must only be used by
>> svk, the usual usage is to mirror a regular s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Joern RENNECKE wrote:
| Daniel Berlin wrote:
|
|>
|> And towards this end,i'm working on making blame a lot faster
|>
|>
|
| Will this also cover annotate using an -r option to go past the last
| reformatting
| delta?
|
|> Other than that, what operatio
On Friday, February 11, 2005, at 05:29 PM, Daniel Berlin wrote:
I'll keep the last branchpoint of each branch for the initial import
Won't work either... Sometimes we reuses merge labels in non-obvious
ways. top-200501-merge and top-200502-merge both exist, the two were
used for, say, treeprof
> >
> > You can't mix svn and svk commits against the same repo. It confuses svk
> > (not svn).
> >
> > You can use svk readonly, of course.
>
> Actually, that's not quite right. While svk's depot must only be used by
> svk, the usual usage is to mirror a regular subversion repository with
> svk
Daniel Berlin wrote:
You can't mix svn and svk commits against the same repo. It confuses svk
(not svn).
You can use svk readonly, of course.
Actually, that's not quite right. While svk's depot must only be used by
svk, the usual usage is to mirror a regular subversion repository with
svk into a sv
On Fri, 2005-02-11 at 10:06 -0800, Mike Stump wrote:
> On Thursday, February 10, 2005, at 03:42 PM, Daniel Berlin wrote:
>
> > On Thu, 2005-02-10 at 15:25 -0800, Mike Stump wrote:
> >> On Feb 9, 2005, at 8:54 PM, Daniel Berlin wrote:
> >>> I also plan on excluding merge tags
> >>
> >> The last me
On Fri, 2005-02-11 at 11:19 -0800, Mike Stump wrote:
> On Thursday, February 10, 2005, at 06:13 PM, Richard Kenner wrote:
> > I was concerned about the difficulty in building svn and must say that
> > I
> > wasn't at all encouraged by this report.
>
> I would instead, look to the people that kno
On Fri, 2005-02-11 at 17:13 +, Joern RENNECKE wrote:
> Joseph S. Myers wrote:
>
> >
> >
> >You mean the revision number of the whole checked out tree, which the
> >"svnversion" utility will tell you in any checked out svn tree (including
> >whether the tree is modified or mixed version).
On Fri, 2005-02-11 at 12:08 -0500, Daniel Jacobowitz wrote:
> On Fri, Feb 11, 2005 at 12:00:26PM -0500, Daniel Berlin wrote:
> >
> > >
> > >
> > > >Because if it's a show stopper, then so will be arch, monotone, or any
> > > >of our other replacements (they all either store the entire repo on
On Fri, 2005-02-11 at 17:24 +, Richard Earnshaw wrote:
> On Fri, 2005-02-11 at 17:11, Joern RENNECKE wrote:
>
> > Moreover, I often want just a quick look at the source, and a checkout
> > has quite
> > a long latency for that.
>
> It ought to be less bad for SVN than CVS, particularly for o
On Thursday, February 10, 2005, at 06:13 PM, Richard Kenner wrote:
I was concerned about the difficulty in building svn and must say that
I
wasn't at all encouraged by this report.
I would instead, look to the people that know how to do it well, to
post something up on the wiki pages on how to d
On Thursday, February 10, 2005, at 03:42 PM, Daniel Berlin wrote:
On Thu, 2005-02-10 at 15:25 -0800, Mike Stump wrote:
On Feb 9, 2005, at 8:54 PM, Daniel Berlin wrote:
I also plan on excluding merge tags
The last merge tag on active branches should be kept, as they would be
used for the next merge
Richard Earnshaw wrote:
Huh? Why would I want to copy the binaries?
Sorry, I must have mis-understood. I thought you wanted to keep
binaries of builds around so that you could work out quickly *when* a
regression had been introduced, even if you hadn't tested a particular
combination
On Fri, 2005-02-11 at 17:11, Joern RENNECKE wrote:
> Moreover, I often want just a quick look at the source, and a checkout
> has quite
> a long latency for that.
It ought to be less bad for SVN than CVS, particularly for older code,
and branches. Though I agree it's not going to be zero.
> An
Joseph S. Myers wrote:
You mean the revision number of the whole checked out tree, which the
"svnversion" utility will tell you in any checked out svn tree (including
whether the tree is modified or mixed version). Given such a number, if
you don't intend to do svn operations on that tree
* Daniel Berlin:
>> You could be right, but I don't see how. Once you've set the revision
>> numbers, can you really go back and insert earlier revision numbers?
> Only by dumping and reloading.
Yes, but you don't want to do this as soon as revision numbers are
used in bug reports, mailing list
Richard Earnshaw wrote:
Why do you need to keep the source around at all (unless you are
actively working on that version)? All you need is the single revision
number string and you can guarantee to get exactly that source code back
at any time you want, should you need it.
Only while the
On Fri, Feb 11, 2005 at 12:00:26PM -0500, Daniel Berlin wrote:
>
> >
> >
> > >Because if it's a show stopper, then so will be arch, monotone, or any
> > >of our other replacements (they all either store the entire repo on your
> > >disk, or have stuff in the working copy), and we will be stuc
>
>
> >Because if it's a show stopper, then so will be arch, monotone, or any
> >of our other replacements (they all either store the entire repo on your
> >disk, or have stuff in the working copy), and we will be stuck with cvs
> >until everyone is happy to use up double/whatever disk.
> >
On Fri, 11 Feb 2005, Joern RENNECKE wrote:
> revision numbers of the checkedout files,
You mean the revision number of the whole checked out tree, which the
"svnversion" utility will tell you in any checked out svn tree (including
whether the tree is modified or mixed version). Given such a nu
On Fri, 2005-02-11 at 17:20 +0100, Richard Guenther wrote:
> On Fri, 11 Feb 2005 15:29:11 +, Joern RENNECKE
> <[EMAIL PROTECTED]> wrote:
> > Daniel Berlin wrote:
> >
> > >
> > >
> > >>Because svn keeps an extra pristine copy for checkouts, I'll have to use
> > >>svn export for
> > >>automatic
On Fri, 2005-02-11 at 16:35, Joern RENNECKE wrote:
> Actually, having one copy of the entire repository might be cheaper than
> having
> several dozen double checkouts. But then, having no firm, easily memorized
> revision numbers is certainly a much larger issue. I understand that
> distribut
Daniel Berlin wrote:
Then you are correct, the only way to do what you want is export, or cp
excluding the .svn directories.
Do you consider this a show stopper, or are you willing to export your
trees?
No, I don't think it is a show stopper, but it is a drawback.
The plan is to have the re
On Fri, 11 Feb 2005 15:29:11 +, Joern RENNECKE
<[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
>
> >
> >
> >>Because svn keeps an extra pristine copy for checkouts, I'll have to use
> >>svn export for
> >>automatic regression tests.
> >>
> >>
> >
> >I don't understand why.
> >Is this because
On Fri, 2005-02-11 at 15:29 +, Joern RENNECKE wrote:
> Daniel Berlin wrote:
>
> >
> >
> >>Because svn keeps an extra pristine copy for checkouts, I'll have to use
> >>svn export for
> >>automatic regression tests.
> >>
> >>
> >
> >I don't understand why.
> >Is this because of the am
Daniel Berlin wrote:
Because svn keeps an extra pristine copy for checkouts, I'll have to use
svn export for
automatic regression tests.
I don't understand why.
Is this because of the amount of space the working copy takes up?
Yes. Sometimes stuff breaks and you don't notice it rig
Richard Guenther wrote:
> On Wed, 09 Feb 2005 00:11:54 -0500, Daniel Berlin <[EMAIL PROTECTED]>
> wrote:
>> (Thanks very much to Al Stone of HP for hosting the test repo on
>> toolchain.org! This would not have been possible without him)
>
> Tried it, including builting svn on a Debian woody mac
On Fri, 2005-02-11 at 13:28 +, Joern RENNECKE wrote:
> Daniel Berlin wrote:
>
> >
> >
> >And towards this end,i'm working on making blame a lot faster
> Will this also cover annotate using an -r option to go past the last
> reformatting
> delta?
>
yes.
> >Other than that, what operati
On Fri, 2005-02-11 at 11:19 +, Chris Jefferson wrote:
> Daniel Berlin wrote:
>
> > As the help page says, feel free to try things.
> > Please ask me (either email or irc) if you need help.
> > However, the very well written book at http://svnbook.red-bean.com/1.1
> > probably also has the answ
Daniel Berlin wrote:
And towards this end,i'm working on making blame a lot faster
Will this also cover annotate using an -r option to go past the last
reformatting
delta?
Other than that, what operations are people still worried about the
slowness of?
Because svn keeps an extra pristi
On Wed, 09 Feb 2005 00:11:54 -0500, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> (Thanks very much to Al Stone of HP for hosting the test repo on
> toolchain.org! This would not have been possible without him)
Tried it, including builting svn on a Debian woody machine without
root access and
proble
Are you just I'll informed or plain . ? ( Sorry if it comes off a bit
rough ).
Subversion have been self hosting since a year or more, and as for significant
other projects apache is one :-) ...
You could have googled a bit before blurting out obviously false statements.
A good place
On Thu, 2005-02-10 at 18:41, Joseph S. Myers wrote:
> On Thu, 10 Feb 2005, Daniel Berlin wrote:
>
> > The only way to properly do this then is to just hack up the rcs files
> > with the old-gcc data, where approriate, and increment all the other
> > revision numbers.
>
> So does anyone wish to wr
> From: Daniel Berlin <[EMAIL PROTECTED]>
>> On Thu, 2005-02-10 at 22:32 -0500, Paul Schlie wrote:
>> Out of curiosity, although svn certainly seems attractive, are there any
>> concerns observing that:
>>
>> - ironically it seems that the svn isn't itself under svn control but cvs?
> What?
> It's
Marcin Dalecki wrote:
> OK. I just took a redhat spec as configure command template. As it
> turns out this
> was a mistake on my part... argh! JBLD was once again the root of the
> problem.
> Unfortunately due to this I didn't notice that subversion packages
> apr/, apr-utils/, neon/ and db4/ as
On 2005-02-11, at 05:43, Daniel Berlin wrote:
In fact, if you look at the web page for APR, you can discover exactly
why it was created, and what it does, and then if you look at the
history of subversion, you can discover why apr was used for these
things, instead of reimplementing the wheel again
Paul Schlie wrote:
> Out of curiosity, although svn certainly seems attractive, are there any
> concerns observing that:
>
> - ironically it seems that the svn isn't itself under svn control but cvs?
svn was initially developed in cvs, but has been self-hosted since August
2001. You must have so
On 2005-02-11, at 04:51, Daniel Berlin wrote:
Against my better judgement, i'll respond anyway.
On Fri, 2005-02-11 at 03:50 +0100, Marcin Dalecki wrote:
On 2005-02-11, at 02:19, Daniel Berlin wrote:
Uh, why do you want the server stuff for gcc purposes?
Just curious. Why not? If I want to try it ou
On Fri, 2005-02-11 at 02:20 +, Joseph S. Myers wrote:
> On Thu, 10 Feb 2005, Daniel Berlin wrote:
>
> > It *only* sends compressed texts, there is no need to pass extra
> > options.
>
> Although checkout/update are probably the normal use cases which use the
> bulk of the bandwidth - along w
On Thu, 2005-02-10 at 23:33 -0500, Daniel Berlin wrote:
> On Fri, 2005-02-11 at 04:39 +0100, Marcin Dalecki wrote:
> > On 2005-02-11, at 04:23, Daniel Berlin wrote:
> > >>>
> > > It was perfectly fair. He's complaining the source has dependencies,
> > > and
> > > uses configure to find out what is
On Fri, 2005-02-11 at 04:39 +0100, Marcin Dalecki wrote:
> On 2005-02-11, at 04:23, Daniel Berlin wrote:
> >>>
> > It was perfectly fair. He's complaining the source has dependencies,
> > and
> > uses configure to find out what is available, and complains when it
> > can't find the things it absol
On 2005-02-11, at 04:23, Daniel Berlin wrote:
It was perfectly fair. He's complaining the source has dependencies,
and
uses configure to find out what is available, and complains when it
can't find the things it absolutely depends on.
Because apr and apr-util are providing things subversion doesn
On Thu, 2005-02-10 at 22:32 -0500, Paul Schlie wrote:
> Out of curiosity, although svn certainly seems attractive, are there any
> concerns observing that:
>
> - ironically it seems that the svn isn't itself under svn control but cvs?
What?
It's been under subversion control pretty much since day
Against my better judgement, i'll respond anyway.
On Fri, 2005-02-11 at 03:50 +0100, Marcin Dalecki wrote:
> On 2005-02-11, at 02:19, Daniel Berlin wrote:
> >
> > Uh, why do you want the server stuff for gcc purposes?
>
> Just curious. Why not? If I want to try it out I want to try it out on
> m
Out of curiosity, although svn certainly seems attractive, are there any
concerns observing that:
- ironically it seems that the svn isn't itself under svn control but cvs?
Has svn ever been relied upon for a significant open source project?
- there doesn't seem to be an analogous svn web-based
On Thu, 2005-02-10 at 22:00 -0500, Andrew Pinski wrote:
> On Feb 10, 2005, at 9:13 PM, Richard Kenner wrote:
>
> > Next time you don't want to deal with configuring source, install
> > the
> > binaries.
> >
> > I don't think that's fair. There are a very wide variety of machines
> > used
On Fri, 2005-02-11 at 03:50 +0100, Marcin Dalecki wrote:
> On 2005-02-11, at 02:19, Daniel Berlin wrote:
> >
> > Uh, why do you want the server stuff for gcc purposes?
>
> Just curious. Why not? If I want to try it out I want to try it out on
> my own
> repos too. Maybe I was just too optimistic
On Feb 10, 2005, at 9:13 PM, Richard Kenner wrote:
Next time you don't want to deal with configuring source, install
the
binaries.
I don't think that's fair. There are a very wide variety of machines
used for GCC development and we want to *encourage* that. Plus, some
people may use NFS
On 2005-02-11, at 02:19, Daniel Berlin wrote:
Uh, why do you want the server stuff for gcc purposes?
Just curious. Why not? If I want to try it out I want to try it out on
my own
repos too. Maybe I was just too optimistic about it. And then I simply
didn't know up front what I will get - just the
On Thu, 10 Feb 2005, Daniel Berlin wrote:
> It *only* sends compressed texts, there is no need to pass extra
> options.
Although checkout/update are probably the normal use cases which use the
bulk of the bandwidth - along with commit where svn can send diffs and cvs
needs to upload the whole c
Next time you don't want to deal with configuring source, install the
binaries.
I don't think that's fair. There are a very wide variety of machines
used for GCC development and we want to *encourage* that. Plus, some
people may use NFS and do filesystem stuff on a different machine tha
> Hoewver, please not that control c'ing cvs at the wrong time will cause
> repository corruption as well. Subversion just doesn't let you do it
> during the small time windows where
^^
where it will require the database code to go have to recover and
cleanup the transaction, as some people
69 matches
Mail list logo
