Details for svn test repository

[Daniel Berlin]

(Thanks very much to Al Stone of HP for hosting the test repo on
toolchain.org! This would not have been possible without him)

http://gcc.gnu.org/wiki/SvnHelp has details on how to work with svn,
including the username and password to use when committing[1], how to
check out the trunk, how to work with things, etc.

Again, please note that i did not convert all the tags for this test
repo.

We have >1000 tags. Of those, all but about 100 are bs tags (ie merging
tags, unlabeled tags from rtag -F).
There are also 800 unlabeled branches i deleted in the latest revision
of the branches subdir, all from rtag -F usage.

I have asked Al to add the repository to the websvn viewer when he gets
to it.

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 answers (such as what the status flags mean, etc)

I would also suggest making sure you have at least svn 1.1.2 to access
the repo.

[1] anonymous is read only, it will only ask you for a username and
password when you commit

[Joseph S. Myers]

Post by Daniel Berlin
Again, please note that i did not convert all the tags for this test
repo.
We have >1000 tags. Of those, all but about 100 are bs tags (ie merging
tags, unlabeled tags from rtag -F).
There are also 800 unlabeled branches i deleted in the latest revision
of the branches subdir, all from rtag -F usage.

Is there a need for a flat tag/branch namespace, or could all these odd
tags go e.g. as subdirectories of tags/unlabeled and branches/unlabeled
when the final conversion is done?

Looking at the test repository, I see .cvsignore files as something that
could be removed after the final move is done, being obsoleted by
svn:ignore properties which have been initialized from the .cvsignore
files. But I also note the following:

Why is there a nonempty current svn:ignore property on gcc/doc/ when the
.cvsignore file there was removed some time ago?

How do I view the history of the changes to versioned properties on a
directory? I can view the properties of an individual revision with svn
proplist / svn propget, but svn log on the directory shows changes to the
files in the directory and not changes to the properties of the directory
itself.

[Kevin Puetz]

Post by Joseph S. Myers

Post by Daniel Berlin
Again, please note that i did not convert all the tags for this test
repo.
We have >1000 tags. Of those, all but about 100 are bs tags (ie merging
tags, unlabeled tags from rtag -F).
There are also 800 unlabeled branches i deleted in the latest revision
of the branches subdir, all from rtag -F usage.

Is there a need for a flat tag/branch namespace, or could all these odd
tags go e.g. as subdirectories of tags/unlabeled and branches/unlabeled
when the final conversion is done?

svn itself doesn't care a whit (in fact, the namespace /tags/*,/branches/*
is actually quite optional, though cvs2svn produces it by default). The
names aren't special to svn at all, as both operations are simply copy with
history. Subfolders are fine, multiple/other dirs are are fine, whatever
suits. Most projects develop some sort of scheme though, since svn ls is
the only real facility to learn about available branches, so if it's a
total free-for-all it can be quite hard to follow.

If it's wanted, I have a little perl snippet that can do some regex-based
path rewriting on the dumpfile before you load it to move things around. I
used it to rewrite paths like /tags/Product_1_0_3 to and /trunk/Product to
a structure of /Product/trunk and /Product/tags/1.0.3, separating things
that were logically separate and just comingled in the old CVS namespace on
a previous conversion. It's a pretty simple script.

Or, one can load it as-is and just svn mv things around until the layout is
how you want it (which makes some noise in the history, but nothing
serious).

Post by Joseph S. Myers
Looking at the test repository, I see .cvsignore files as something that
could be removed after the final move is done, being obsoleted by
svn:ignore properties which have been initialized from the .cvsignore
Why is there a nonempty current svn:ignore property on gcc/doc/ when the
.cvsignore file there was removed some time ago?
How do I view the history of the changes to versioned properties on a
directory? I can view the properties of an individual revision with svn
proplist / svn propget, but svn log on the directory shows changes to the
files in the directory and not changes to the properties of the directory
itself.

property changes are included in that log (as well as changes to the files
in it). Unfortunately, though, log doesn't seem to accept -N
(non-recursive), so I guess one has to sort through the chaff.

[Daniel Berlin]

Post by Joseph S. Myers

Post by Daniel Berlin
Again, please note that i did not convert all the tags for this test
repo.
We have >1000 tags. Of those, all but about 100 are bs tags (ie merging
tags, unlabeled tags from rtag -F).
There are also 800 unlabeled branches i deleted in the latest revision
of the branches subdir, all from rtag -F usage.

Is there a need for a flat tag/branch namespace, or could all these odd
tags go e.g. as subdirectories of tags/unlabeled and branches/unlabeled
when the final conversion is done?

All of the unlabeled tags/branches really shouldn't be there at all,
actually. They have nothing in them.
I plan on excluding them from the final dump (if and when we decide to
move to subversion).
I also plan on excluding merge tags

Post by Joseph S. Myers
Looking at the test repository, I see .cvsignore files as something that
could be removed after the final move is done, being obsoleted by
svn:ignore properties which have been initialized from the .cvsignore
Why is there a nonempty current svn:ignore property on gcc/doc/ when the
.cvsignore file there was removed some time ago?

Because it didn't notice it was deleted (IE it picked it up along the
way).

Post by Joseph S. Myers
How do I view the history of the changes to versioned properties on a
directory? I can view the properties of an individual revision with svn
proplist / svn propget, but svn log on the directory shows changes to the
files in the directory and not changes to the properties of the directory
itself.

If you add -v it will tell you what paths changed.
Then you have to do it the normal diff way to see what actually changed.
ie:
***@linux:~/bobw/bob> svn diff

Property changes on:
___________________________________________________________________
Name: foo
- bar2
+ bar


Index: fred.c
===================================================================
--- fred.c (revision 4)
+++ fred.c (working copy)
@@ -0,0 +1 @@
+add some text



By the way guys, i'm in the midst of speeding up blame/annotate/ann by a
very large factor. Please do not use it in the meanwhile, as it is
ridiculously slow for our files :)

[Joseph S. Myers]

Post by Daniel Berlin
All of the unlabeled tags/branches really shouldn't be there at all,
actually. They have nothing in them.
I plan on excluding them from the final dump (if and when we decide to
move to subversion).
I also plan on excluding merge tags

Likewise the old snapshot tags as also being something best found through
looking at the old repository directly if someone wishes to do so? Is
there a list of the tags proposed to be excluded? (I could see merge tags
for currently developed branches as being of use to have in the new
repository, though for those for dead branches the old repository should
suffice.)

Post by Daniel Berlin

Post by Joseph S. Myers
How do I view the history of the changes to versioned properties on a
directory? I can view the properties of an individual revision with svn
proplist / svn propget, but svn log on the directory shows changes to the
files in the directory and not changes to the properties of the directory
itself.

If you add -v it will tell you what paths changed.

So the indication is that, for example, "svn log -v ." in gcc/doc shows
the directory itself as a path that changed in version 55947, implying a
property change, so looking for the directory in the log -v output and
ignoring all the other log entries shows the changes to (the properties
of) a directory itself?

[Daniel Berlin]

Post by Joseph S. Myers

Post by Daniel Berlin
All of the unlabeled tags/branches really shouldn't be there at all,
actually. They have nothing in them.
I plan on excluding them from the final dump (if and when we decide to
move to subversion).
I also plan on excluding merge tags

Likewise the old snapshot tags as also being something best found through
looking at the old repository directly if someone wishes to do so? Is
there a list of the tags proposed to be excluded? (I could see merge tags
for currently developed branches as being of use to have in the new
repository, though for those for dead branches the old repository should
suffice.)

Post by Daniel Berlin

Post by Joseph S. Myers
How do I view the history of the changes to versioned properties on a
directory? I can view the properties of an individual revision with svn
proplist / svn propget, but svn log on the directory shows changes to the
files in the directory and not changes to the properties of the directory
itself.

If you add -v it will tell you what paths changed.

So the indication is that, for example, "svn log -v ." in gcc/doc shows
the directory itself as a path that changed in version 55947, implying a
property change,

^ on that directory (since files can have properties too)

I don't believe there is a current way to tell that a file's property
changed vs a file's content. Though that should be easy enough to add
to svn if such a differentiation was wanted.

Post by Joseph S. Myers
so looking for the directory in the log -v output and
ignoring all the other log entries shows the changes to (the properties
of) a directory itself?

Right.
We could also request a "property changes only" version of log (plog),
or something, if that is what was wanted. But it might entail
client/server protocol changes (which are not verboten, but require more
testing to make sure everything fails in a graceful way when not
supported), i'd have to look if that is what you wanted.
Just let me know.

[Daniel Berlin]

Post by Daniel Berlin
I don't believe there is a current way to tell that a file's property
changed vs a file's content. Though that should be easy enough to add
to svn if such a differentiation was wanted.

The reason I didn't notice that the svn log -v output had any indication
of the property change in the directory is that I expected it to mention
somewhere the name of the property changed, e.g. to say
M /trunk/gcc/doc (property svn:ignore)
or similar (and likewise for properties added or removed), but I doubt an
imcompatible change to svn log output format is worth doing here.

Post by Daniel Berlin
We could also request a "property changes only" version of log (plog),
or something, if that is what was wanted. But it might entail
client/server protocol changes (which are not verboten, but require more
testing to make sure everything fails in a graceful way when not
supported), i'd have to look if that is what you wanted.

The natural user interface would seem to be allowing -N with log to report
just changes to a directory itself - whether properties or addition or
removal of the directory or any other change Subversion understands as
applying to directories themselves. But I don't know whether that would
need a protocol change.

I can ask.

Another question - how do I view logs for a file which has been deleted,
possibly in a directory which has been deleted?
In CVS, I can do "cvs log
ra.c" if the directory hasn't been deleted, or if the directory has been
deleted then "cvs update -d f; cvs log f/Make-lang.in". But "svn log"
produces errors "Skipped 'ra.c'" or "'f' is not a working copy" and giving
a full svn:// path instead says "svn: File not found: revision 76596, path
'/trunk/gcc/ra.c'". (I don't know if specifying a version number in which
that file existed would do, but needing to locate such a version number
first seems odd.)

The file doesn't actually exist in that revision, so it skips it :)

You want svn log <filename>@rev-that-it-exists
To find rev-that-it-exists, just do log on the parent directory to
discover when it was there, and when it wasn't.

(The most common case in which I have wanted such logs in practice is to
view logs of .texi files from before they moved from gcc/ to gcc/doc/
(which would also be dealt with if cvs2svn could track those moves as
being actual file renames / copies - note gcc.texi changes in that move to
refer to the new file name install-old.texi so that isn't quite just a
case of detecting identical contents of added/removed files, manual hints
might be needed).)

I'm not really sure trying to add this logic into the middle of the
dumper makes sense. It would require a *lot* of work to try to work
around what we know is a failing in cvs.

[Joseph S. Myers]

Post by Daniel Berlin
To find rev-that-it-exists, just do log on the parent directory to
discover when it was there, and when it wasn't.

Doesn't seem to work as described. Take the example of gcc/invoke.texi.
"svn log -v ." in the gcc directory produces 25 MB of output (which from
strace appears to be being transferred across the network uncompressed;
compare simple "cvs -z9 log invoke.texi" which produces output of 50kB
compressed so probably 50kb network bandwidth used). This shows
gcc/invoke.texi being deleted (ignoring subsequent resurrections) in
r24845; the previous change to it being in r24842. But "svn log -v
***@24845" says "Skipped '***@24845'", similarly "svn log
-v ***@24842", "svn log -v -r 24842 invoke.texi", "svn log -v -r
1:24842 invoke.texi", "svn log -v
svn://svn.toolchain.org/svn/gcc/trunk/gcc/***@24842". Eventually
trial and error shows "svn log -v -r 24844:1
svn://svn.toolchain.org/svn/gcc/trunk/gcc/invoke.texi" works. But it
seems rather cumbersome to need to waste 25MB of bandwidth getting logs
for the whole directory to get the logs for an individual file (and in
particular when it was deleted if you want another svn comment to extract
just the logs for that file).

[Daniel Berlin]

Post by Joseph S. Myers

Post by Daniel Berlin
To find rev-that-it-exists, just do log on the parent directory to
discover when it was there, and when it wasn't.

Doesn't seem to work as described. Take the example of gcc/invoke.texi.
"svn log -v ." in the gcc directory produces 25 MB of output (which from
strace appears to be being transferred across the network uncompressed;
compare simple "cvs -z9 log invoke.texi" which produces output of 50kB
compressed so probably 50kb network bandwidth used). This shows
gcc/invoke.texi being deleted (ignoring subsequent resurrections) in
r24845; the previous change to it being in r24842. But "svn log -v
1:24842 invoke.texi", "svn log -v
trial and error shows "svn log -v -r 24844:1
svn://svn.toolchain.org/svn/gcc/trunk/gcc/invoke.texi" works. But it
seems rather cumbersome to need to waste 25MB of bandwidth getting logs
for the whole directory to get the logs for an individual file (and in
particular when it was deleted if you want another svn comment to extract
just the logs for that file).

I have forwarded a url to this thread along to some svn people to see
what's up.

However, i can say that "getting logs for an individual file" means
nothing in svn, because it's versioning trees, not files :).
This is also true of all of the cvs replacements. Only cvs does that
these days :)

[Mike Stump]

Post by Daniel Berlin
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?! If that information can be entered into cvn
some other way, that would be really nice, and obviate the need for
such tags?.

[Daniel Berlin]

Post by Mike Stump

Post by Daniel Berlin
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?!

Uh, you don't need a tag to merge anymore.
:)

Post by Mike Stump
If that information can be entered into cvn
some other way, that would be really nice, and obviate the need for
such tags?.

[Mike Stump]

Post by Daniel Berlin

Post by Mike Stump

Post by Daniel Berlin
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?!

Uh, you don't need a tag to merge anymore.

How could it know what to merge? Take for example, the
apple-ppc-branch for example.

[Daniel Berlin]

Post by Mike Stump

Post by Daniel Berlin

Post by Mike Stump

Post by Daniel Berlin
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?!

Uh, you don't need a tag to merge anymore.

How could it know what to merge?
Take for example, the
apple-ppc-branch for example.

Find the current revision of the apple-ppc-branch using svn info on your
checked out copy.
"svn merge -r<current rev that tells you>:HEAD
svn://svn.toolchain.org/svn/gcc/trunk "

That will merge in all the changes from the HEAD since the last time you
merged.

In general, you don't need a tag to merge, you just need the last global
revision number for your current tree (unlike cvs, where you *have* to
tag every file so you have a global set of revision numbers).

There is actually a tool that automates this using properties so you
don't need to remember anything at all, and also lets you cherry pick
revisions if you want to.
http://www.dellroad.org/svnmerge/index

Even further automated history tracking is planned for future versions
of subversion.

[Geoffrey Keating]

Post by Daniel Berlin
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.

[Daniel Berlin]

Post by Geoffrey Keating

Post by Daniel Berlin
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, i'll try to make a test repo with them all in there, and see
how long it takes.

[Joern RENNECKE]

Post by Daniel Berlin
All of the unlabeled tags/branches really shouldn't be there at all,
actually. They have nothing in them.
I plan on excluding them from the final dump (if and when we decide to
move to subversion).
I also plan on excluding merge tags

While you are at re-arranging what's in the repository... could you also
include the pre-egcs RCS versions in the converted archive?
As it is now, when you want to understand what a piece of code is doing
there, you sometimes just hit a wall when you come to version 1.1 .

[Joseph S. Myers]

Post by Joern RENNECKE
While you are at re-arranging what's in the repository... could you also
include the pre-egcs RCS versions in the converted archive?
As it is now, when you want to understand what a piece of code is doing
there, you sometimes just hit a wall when you come to version 1.1 .

The trouble with including old-gcc like that is that old-gcc (GCC2)
development continued for a couple of years after EGCS started. So the
versions in old-gcc up to the snapshot from which EGCS started could
reasonably count as going immediately before version 1.1 of the EGCS
files, but subsequent versions in old-gcc either couldn't be included in
this way or would need to be transformed into a branch (separate, of
course, from the vendor branch in the current repository into which some
versions of old-gcc were imported and which appears in the svn
repository as branches/gcc3).

[Daniel Berlin]

Post by Joseph S. Myers

Post by Joern RENNECKE
While you are at re-arranging what's in the repository... could you also
include the pre-egcs RCS versions in the converted archive?
As it is now, when you want to understand what a piece of code is doing
there, you sometimes just hit a wall when you come to version 1.1 .

The trouble with including old-gcc like that is that old-gcc (GCC2)
development continued for a couple of years after EGCS started. So the
versions in old-gcc up to the snapshot from which EGCS started could
reasonably count as going immediately before version 1.1 of the EGCS
files, but subsequent versions in old-gcc either couldn't be included in
this way or would need to be transformed into a branch (separate, of
course, from the vendor branch in the current repository into which some
versions of old-gcc were imported and which appears in the svn
repository as branches/gcc3).

Oh, i wasn't aware of this.

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.
Trying to shoehorn this into the converter would be mayhem :)

[Joseph S. Myers]

Post by Daniel Berlin
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 write a pre-pass which hacks up the old-gcc and gcc
RCS files into something good to pass to cvs2svn (which could then be used
as a stage in future trial conversions, and the final conversion)?

To my mind some sort of detection of file renames is at least as desirable
as doing anything with old-gcc; after all, the history that file renames
make more difficult to see is mostly more recent than that in old-gcc.
(And I've long argued that we shouldn't hold up rearrangements involving
moving files on the grounds that this confuses history because we can live
with the confusion for now and it could all be sorted out in the convertor
to a new system.) <http://cvs2svn.tigris.org/issues/show_bug.cgi?id=1>
has lots of discussion of how to auto-detect renames but though
auto-detection would be useful I think that most of the important cases in
GCC could be handled through a manual hints file with entries like

gcc/install.texi -> gcc/doc/install-old.texi

where if a changeset (for mainline or any branch) removes the first named
file and adds the second named file, this is taken as a rename
(copy+delete).

[Joern RENNECKE]

Post by Joseph S. Myers
The trouble with including old-gcc like that is that old-gcc (GCC2)
development continued for a couple of years after EGCS started. So the
versions in old-gcc up to the snapshot from which EGCS started could
reasonably count as going immediately before version 1.1 of the EGCS
files, but subsequent versions in old-gcc either couldn't be included in
this way or would need to be transformed into a branch (separate, of
course, from the vendor branch in the current repository into which some
versions of old-gcc were imported and which appears in the svn
repository as branches/gcc3).

I think the priority would be to get the base versions sorted out; the
branch could be grafted on later when desired.

But if we can't get a suitably prepared old-gcc repo on time, it would be better
to include all of it rather than none of it.
Such a stop-gap solution would also allow later tinkering, as you could
later delete the versions that are not applicable and still keep all the
remaining versions constant; you would just get a range of versions that
are all identical.

Post by Joseph S. Myers
So does anyone wish to write a pre-pass which hacks up the old-gcc and gcc
RCS files into something good to pass to cvs2svn (which could then be used
as a stage in future trial conversions, and the final conversion)?

IIRC you can use cvs admin to delete deltas in a repository (if you have
the support
compiled in and have the privileges). So i think what we need can be
done by taking
a copy of the repository, and for every file at the head, delete all
deltas between the
egcs branch tag and head. It wouldn't find any deleted files, but I
don't think that
would be significant for seeding the repository.

Post by Joseph S. Myers
To my mind some sort of detection of file renames is at least as desirable
as doing anything with old-gcc; after all, the history that file renames
make more difficult to see is mostly more recent than that in old-gcc.

Agreed.

OTOH, a number of thre renamed files are documentation and therefore not as
vital to track history for like cse.c, combine.c or reload*.c

[Joern RENNECKE]

Post by Joseph S. Myers
So does anyone wish to write a pre-pass which hacks up the old-gcc and gcc
RCS files into something good to pass to cvs2svn (which could then be used
as a stage in future trial conversions, and the final conversion)?

P.S.: I suppose we should first try to find out if the FSF (or anyone
else) has backups of
the repository from around the time the egcs branch was made.

[Mike Stump]

Post by Joern RENNECKE
P.S.: I suppose we should first try to find out if the FSF (or anyone
else) has backups of
the repository from around the time the egcs branch was made.

Should be as easy as deleting all the deltas mades after date X on all
files from old-gcc?.

[Ian Lance Taylor]

Post by Mike Stump

Post by Joern RENNECKE
P.S.: I suppose we should first try to find out if the FSF (or
anyone else) has backups of
the repository from around the time the egcs branch was made.

Should be as easy as deleting all the deltas mades after date X on all
files from old-gcc?.

It's not quite the same, though, since egcs started from a sanitized
Cygnus repository, which was not identical to the FSF repository.

Not that I think we necessarily need to worry about to that degree.

Ian

[Richard Earnshaw]

Post by Joseph S. Myers

Post by Daniel Berlin
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 write a pre-pass which hacks up the old-gcc and gcc
RCS files into something good to pass to cvs2svn (which could then be used
as a stage in future trial conversions, and the final conversion)?

It ought to be possible to obsolete all versions on the trunk in old-gcc
after the fork was made, and in current-gcc to bump the major revision
number for all commits (not in the live repository of course).

A real guru might be able to force all the old-gcc work post split to
appear to have been done on a branch...

R.

[Mark Mitchell]

Post by Daniel Berlin
Oh, i wasn't aware of this.

I don't think there's much value in trying to include GCC 2 in a new
repository. We're not running a museum.

[Ian Lance Taylor]

Post by Mark Mitchell

Post by Daniel Berlin
Oh, i wasn't aware of this.

I don't think there's much value in trying to include GCC 2 in a new
repository. We're not running a museum.

I think it can be quite helpful when tracking down how code was
developed. I often find myself tracking back into the old-gcc
repository to figure out when a bug was introduced.

I don't think it should be a requirement, but I think it would be very
helpful. And switching to a new version control system is likely to
be our only chance to incorporate it.

Ian

[Mark Mitchell]

Post by Ian Lance Taylor
I think it can be quite helpful when tracking down how code was
developed. I often find myself tracking back into the old-gcc
repository to figure out when a bug was introduced.

Sure; we maintain GCC back as far as GCC 2.7.2, so we do have to go
fishing sometimes.

But, this is mission creep.

All we should be trying to do at this stage is get to a new VCS that is
no worse than CVS on the axes we care about. I can't see any
fundamental reason that we couldn't go back and add history later, if
that's compelling and someone wants to do it. The same goes for file
rename information: we're getting by without that now, and we can add it
in later if need be.

I think all we should be doing is making sure that the new system is at
least as reliable as CVS, easy enough to use, faster for key operations,
and provides good infrastructure for getting things like file renaming
handled correctly going forward.

Let's not raise the bar higher than it needs to be.

[Daniel Berlin]

Post by Mark Mitchell

Post by Ian Lance Taylor
I think it can be quite helpful when tracking down how code was
developed. I often find myself tracking back into the old-gcc
repository to figure out when a bug was introduced.

Sure; we maintain GCC back as far as GCC 2.7.2, so we do have to go
fishing sometimes.
But, this is mission creep.
All we should be trying to do at this stage is get to a new VCS that is
no worse than CVS on the axes we care about. I can't see any
fundamental reason that we couldn't go back and add history later, if
that's compelling and someone wants to do it. The same goes for file
rename information: we're getting by without that now, and we can add it
in later if need be.
I think all we should be doing is making sure that the new system is at
least as reliable as CVS, easy enough to use, faster for key operations,
and provides good infrastructure for getting things like file renaming
handled correctly going forward.

And towards this end,i'm working on making blame a lot faster
Other than that, what operations are people still worried about the
slowness of?

[Joern RENNECKE]

Post by Daniel Berlin
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?

Post by Daniel Berlin
Other than that, what operations are people still worried about the
slowness of?

Because svn keeps an extra pristine copy for checkouts, I'll have to use
svn export for
automatic regression tests. With cvs, the overhead of the cvs
information is small,
so I could use checkouts, and when I wanted to work on / test some
patches with a
baseline known to build and to have a specific set of regressions, I
just copied over the
checked out tree and started working on it. With svn, I'll have to do a
fresh checkout of
the files/directories I'll be working on. The book mentions that there
is an intent to make
the extra pristine copy optional, but AFAICT this isn't something that
is available now.

[Daniel Berlin]

Post by Joern RENNECKE

Post by Daniel Berlin
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.

Post by Joern RENNECKE

Post by Daniel Berlin
Other than that, what operations are people still worried about the
slowness of?

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?

[Joern RENNECKE]

Post by Daniel Berlin

Post by Joern RENNECKE
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 right away (E.g.
because the
feature is not automatically tested, or because of noise from other test
failures).
So it is useful to keep several month worth of test builds around.
Doubling the
amount of space taken up by this is not acceptable.

Ideally, you could do an read-only checkout, and iin addition to the
actual files
you'd only store the repository location and revision numbers of the
checkedout
files, and maybe an md5 od SHA1 hash.
When you then later decide that you want to work on some of the source, you
could tell svn to create the pristine copies in for a set of files
and/or sub-trees
and change the files to read-write (taking umask into account where
available).

[Daniel Berlin]

Post by Joern RENNECKE

Post by Daniel Berlin

Post by Joern RENNECKE
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 right away (E.g.
because the
feature is not automatically tested, or because of noise from other test
failures).
So it is useful to keep several month worth of test builds around.
Doubling the
amount of space taken up by this is not acceptable.

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

Again guys, i'm not trying to force anything on anyone.
If we don't want to move, we don't *have* to move.
I just have a hard time seeing us using cvs for another 5-10 years, and
i have a hard time seeing what is going to miraculously change about our
repository between then and now.
The only thing i see changing is maybe things like svn grow the ability
to compress their working copies (already been suggested and i believe
someone is working on it), or whatever.
I highly doubt the basic fact that the checkouts take more space will
change, even if the constant changes from 2.5 to 1.5.
So if the fact that checkouts are larger is a showstopper for people,
(IE they aren't willing to adjust), we might as well quit evaluating
now :)

[Joern RENNECKE]

Post by Daniel Berlin
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 regression tester find out the current head
revision, and
then export this, and stash away the version number used. I should then be
able to do a checkout of selected files / subtrees if and when it is needed.
I don't know how well the server will take the extra load, but I
wouldn't expect
it to be a major problem.
I also consider this to be a drawback in terms of ease of use, however,
not as
bad as the missing ability in CVS to copy / rename files while keeping the
history.

Post by Daniel Berlin
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.

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
distributed
revision control systems would make it much harder to refer to a particular
version.

[Richard Earnshaw]

Post by Joern RENNECKE
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
distributed
revision control systems would make it much harder to refer to a particular
version.

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.

So you should only need at most one copy of the source in your
regression testing system, and when you copy the binaries, just record
which revision they were built from.

R.

[Joern RENNECKE]

Post by Richard Earnshaw
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 server is up and running, in a sane state, and the
internet connection
to the server machine works all the way from here to there. Which is
not all
the time, I am afraid to say. Someone would also have to hack gdb to
retrieve
the source code via cvs/svn.
Moreover, I often want just a quick look at the source, and a checkout
has quite
a long latency for that.
And finally, sometimes bugs in the checkout process or changes in the
modules file
can cause strange build failures.
If I don't keep around the sources axactly they were checked out, there
is no guarantee
that the build (or non-build) can be reproduced, and if it isn't
reproducible because of
a transient problem, the best way to start is to compare the sources of
the original
checkout with the new checkout... oops, you were just talking of not
having these.

Post by Richard Earnshaw
So you should only need at most one copy of the source in your
regression testing system, and when you copy the binaries, just record
which revision they were built from.

Huh? Why would I want to copy the binaries?

[Richard Earnshaw]

Post by Joern RENNECKE
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.

Post by Joern RENNECKE
And finally, sometimes bugs in the checkout process or changes in the
modules file
can cause strange build failures.

I'm not sure what SVN has in the way of modules support, but I'd be
*very* surprised if anything it had wasn't version controlled, so this
should be much less of a problem than it can be with CVS.

Post by Joern RENNECKE

Post by Richard Earnshaw
So you should only need at most one copy of the source in your
regression testing system, and when you copy the binaries, just record
which revision they were built from.

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 that build originally.

R.

[Joern RENNECKE]

Post by Richard Earnshaw

Post by Joern RENNECKE
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 that build originally.
R.

Yes, I keep the binaries around, but I just leave them where they were built
(till I eventually need to reclaim the space).

[Daniel Berlin]

Post by Richard Earnshaw

Post by Joern RENNECKE
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.

Post by Joern RENNECKE
And finally, sometimes bugs in the checkout process or changes in the
modules file
can cause strange build failures.

I'm not sure what SVN has in the way of modules support, but I'd be
*very* surprised if anything it had wasn't version controlled, so this
should be much less of a problem than it can be with CVS.

It has svn:externals, which is more or less the modules file on crack.

http://svnbook.red-bean.com/en/1.1/ch07s03.html

(It properly updates the modules when thye need to be updated. The only
thing that doesn't work is recursive commits through external
repositories. You need to run commit in each dir seperately).

[Daniel Berlin]

Post by Joern RENNECKE

Post by Daniel Berlin
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.

Actually, having one copy of the entire repository might be cheaper than
having
several dozen double checkouts.

Yes, at some point the double space outruns the cost of the entire repo.
For gcc, the cost of the entire repo is 4.4 gig right now.
For your case, it might be cheaper to rsync the repo (unlike cvs, for
each extra global revision to download, it's going to be 1 new file, and
the old files won't be different. So it's going to be a *very fast*
rsync), and export directly from that.

Post by Joern RENNECKE
But then, having no firm, easilywaiting : memorized
revision numbers is certainly a much larger issue. I understand that
distributed
revision control systems would me ay iit much harder to refer to a particular
version.

yeah, this is because they generally have some UUID or something as part
of the revision number.

[Daniel Jacobowitz]

Post by Daniel Berlin

Post by Joern RENNECKE

Post by Daniel Berlin
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.

Actually, having one copy of the entire repository might be cheaper than
having
several dozen double checkouts.

Yes, at some point the double space outruns the cost of the entire repo.
For gcc, the cost of the entire repo is 4.4 gig right now.
For your case, it might be cheaper to rsync the repo (unlike cvs, for
each extra global revision to download, it's going to be 1 new file, and
the old files won't be different. So it's going to be a *very fast*
rsync), and export directly from that.

Since I think this is a very important point, I'm going to contribute a
couple of supporting statistics...

The CVS repository is about 2.6GB. So, smaller than the subversion
repository, but not by enough to bug me. Rsyncing it takes forever.
Cvsup updating is very fast, however. I expect rsyncing the SVN
repository to be comparably fast (less data transfered, less writing on
client side, more reading on server side).

A complete CVS checkout is 260MB, or about 10% of the repository. If
you've just got the one checkout, the checkouts win. I've got a dozen
right now; from what I've been hearing, svk would be the biggest win
for me.

[Daniel Berlin]

Post by Daniel Jacobowitz

Post by Daniel Berlin

Post by Joern RENNECKE

Post by Daniel Berlin
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.

Actually, having one copy of the entire repository might be cheaper than
having
several dozen double checkouts.

Yes, at some point the double space outruns the cost of the entire repo.
For gcc, the cost of the entire repo is 4.4 gig right now.
For your case, it might be cheaper to rsync the repo (unlike cvs, for
each extra global revision to download, it's going to be 1 new file, and
the old files won't be different. So it's going to be a *very fast*
rsync), and export directly from that.

Since I think this is a very important point, I'm going to contribute a
couple of supporting statistics...
The CVS repository is about 2.6GB.

3200989 cvsfiles

oh, wait, that includes wwwdocs and whatnot, sorry.

Post by Daniel Jacobowitz
A complete CVS checkout is 260MB, or about 10% of the repository. If
you've just got the one checkout, the checkouts win. I've got a dozen
right now; from what I've been hearing, svk would be the biggest win
for me.

You can't mix svn and svk commits against the same repo. It confuses svk
(not svn).

You can use svk readonly, of course.

[bd]

Post by Daniel Berlin

Post by Daniel Jacobowitz

Post by Daniel Berlin

Post by Joern RENNECKE

Post by Daniel Berlin
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.

Actually, having one copy of the entire repository might be cheaper than
having
several dozen double checkouts.

Yes, at some point the double space outruns the cost of the entire repo.
For gcc, the cost of the entire repo is 4.4 gig right now.
For your case, it might be cheaper to rsync the repo (unlike cvs, for
each extra global revision to download, it's going to be 1 new file, and
the old files won't be different. So it's going to be a *very fast*
rsync), and export directly from that.

Since I think this is a very important point, I'm going to contribute a
couple of supporting statistics...
The CVS repository is about 2.6GB.

3200989 cvsfiles
oh, wait, that includes wwwdocs and whatnot, sorry.

Post by Daniel Jacobowitz
A complete CVS checkout is 260MB, or about 10% of the repository. If
you've just got the one checkout, the checkouts win. I've got a dozen
right now; from what I've been hearing, svk would be the biggest win
for me.

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 svk depot, then work with it from there using svk. Any
changes in the svn repository are pulled in with svk sync, and any
changes to the mirrored copy are applied to the backing subversion
repository.

For more information: http://svk.elixus.org/?SVKUsage

[Daniel Berlin]

Post by bd

Post by Daniel Berlin
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 svk depot, then work with it from there using svk. Any
changes in the svn repository are pulled in with svk sync, and any
changes to the mirrored copy are applied to the backing subversion
repository.

Except that http://svk.elixus.org/?SVKFAQ

says "Given an svk repository, do you have to use it via svk, or can you
use svn programs to access it?

Short answer: svn programs that only read the repository are working
fine; those who actually write in the repository would bypass svk and
make it fail.
"

[Kevin Puetz]

Post by Daniel Berlin

Post by bd

Post by Daniel Berlin
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 svk depot, then work with it from there using svk. Any
changes in the svn repository are pulled in with svk sync, and any
changes to the mirrored copy are applied to the backing subversion
repository.

Except that http://svk.elixus.org/?SVKFAQ
says "Given an svk repository, do you have to use it via svk, or can you
use svn programs to access it?
Short answer: svn programs that only read the repository are working
fine; those who actually write in the repository would bypass svk and
make it fail.
"

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 to
make your local work visible to others prior to pushing it upstream.

However, none of this doesn't mean you can't use svk as your local client
with a normal svn repository mirrored into the depot. In fact, it's
probably the most common use of svk. This is *not* a readonly setup, as svk
knows how to push commits through and back to upstream. Obviously this can
entail conflict resolution if your local mirror has become a local branch,
since svk also allows you to make commits that you haven't pushed back up
yet, but that's not really different than still having it all loose WC
without a local VCS.

[bd]

Post by Daniel Berlin

Post by bd

Post by Daniel Berlin
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 svk depot, then work with it from there using svk. Any
changes in the svn repository are pulled in with svk sync, and any
changes to the mirrored copy are applied to the backing subversion
repository.

Except that http://svk.elixus.org/?SVKFAQ
says "Given an svk repository, do you have to use it via svk, or can you
use svn programs to access it?
Short answer: svn programs that only read the repository are working
fine; those who actually write in the repository would bypass svk and
make it fail.
"

Vital difference:
This will work:
svk mirror svn://wherever //svnrepo/mirror
# do svk things with //svnrepo/mirror
# do svn things with svn://wherever

This won't work:
svk mirror svn://wherever //svnrepo/mirror
# do svk things with //svnrepo/mirror
# do svn things wioth file://$HOME/.svk/local/svnrepo/mirror

[Daniel Berlin]

Post by Kevin Puetz
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 to
make your local work visible to others prior to pushing it upstream.
However, none of this doesn't mean you can't use svk as your local client
with a normal svn repository mirrored into the depot. In fact, it's
probably the most common use of svk. This is *not* a readonly setup, as svk
knows how to push commits through and back to upstream. Obviously this can
entail conflict resolution if your local mirror has become a local branch,
since svk also allows you to make commits that you haven't pushed back up
yet, but that's not really different than still having it all loose WC
without a local VCS.

Oh, okay, i get it now.
:)
Thanks for all the clarficiation

[Richard Guenther]

On Fri, 11 Feb 2005 15:29:11 +0000, Joern RENNECKE

Post by Joern RENNECKE

Post by Daniel Berlin

Post by Joern RENNECKE
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 right away (E.g.
because the
feature is not automatically tested, or because of noise from other test
failures).
So it is useful to keep several month worth of test builds around.
Doubling the
amount of space taken up by this is not acceptable.

If cp -Rl will not confuse svn, as Kevin suggests, first copying the
repository using hard-links for files and then updating the new copy
should save a lot of disk space. I'll try, if svk helps here, too.

Richard.

[Daniel Berlin]

Post by Richard Guenther
On Fri, 11 Feb 2005 15:29:11 +0000, Joern RENNECKE

Post by Joern RENNECKE

Post by Daniel Berlin

Post by Joern RENNECKE
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 right away (E.g.
because the
feature is not automatically tested, or because of noise from other test
failures).
So it is useful to keep several month worth of test builds around.
Doubling the
amount of space taken up by this is not acceptable.

If cp -Rl will not confuse svn,

I honestly do not know if it will.
If it does, and it's not too much of a hassle to make it *not* confuse
svn, i'm sure they'll include such a feature if i coded it up.
But someone would have to tell me what i need to code first :)

[Joseph S. Myers]

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 number, if
you don't intend to do svn operations on that tree afterwards you can
remove the .svn directories and reconstruct the checked out tree using the
version number later.

[Joern RENNECKE]

Post by Joseph S. Myers
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 afterwards you can
remove the .svn directories and reconstruct the checked out tree using the
version number later.

Is there an svn command to do that without doing a new checkout from the
repository?

[Daniel Berlin]

Post by Joern RENNECKE

Post by Joseph S. Myers
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 afterwards you can
remove the .svn directories and reconstruct the checked out tree using the
version number later.

Is there an svn command to do that without doing a new checkout from the
repository?

You mean tell you what the current version of the repo is?
svnlook can do it, but it requires direct access to the repo.
I could always make something that just prints out svnlook youngest
<repo> to a socket and closes the connection (so you could netcat it or
whatever), if that is what you need.

[bd]

Post by Daniel Berlin

Post by Joern RENNECKE

Post by Joseph S. Myers
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 afterwards you can
remove the .svn directories and reconstruct the checked out tree using the
version number later.

Is there an svn command to do that without doing a new checkout from the
repository?

You mean tell you what the current version of the repo is?
svnlook can do it, but it requires direct access to the repo.
I could always make something that just prints out svnlook youngest
<repo> to a socket and closes the connection (so you could netcat it or
whatever), if that is what you need.

Alternately, parse the output of svn ls -v on the repository root, and
select the highest revision number cited. This requries no changes on
the server.

[bd]

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 operations are people still worried about the
|> slowness of?
|>
|>
|
| Because svn keeps an extra pristine copy for checkouts, I'll have to use
| svn export for
| automatic regression tests. With cvs, the overhead of the cvs
| information is small,
| so I could use checkouts, and when I wanted to work on / test some
| patches with a
| baseline known to build and to have a specific set of regressions, I
| just copied over the
| checked out tree and started working on it. With svn, I'll have to do a
| fresh checkout of
| the files/directories I'll be working on. The book mentions that there
| is an intent to make
| the extra pristine copy optional, but AFAICT this isn't something that
| is available now.

Can't you use a single checkout with svn switch, or patch it and svn
revert when done?

Alternately, use svk, and create local branches for whatever changes you
want to save.

[Ian Lance Taylor]

Post by Mark Mitchell
All we should be trying to do at this stage is get to a new VCS that
is no worse than CVS on the axes we care about. I can't see any
fundamental reason that we couldn't go back and add history later, if
that's compelling and someone wants to do it. The same goes for file
rename information: we're getting by without that now, and we can add
it in later if need be.

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?
Once you've created revisions in which files are not renamed, can you
really insert the file renames? I don't think that would be would
minor hacking; I think it would be major surgery on the revision
control data.

Getting the old history in now, on the other hand, is minor hacking.
I'm perfectly willing to do some work to get it to happen.

If I am wrong, and it can easily be done later, I would be happy to
hear it.

Ian

[Daniel Berlin]

Post by Ian Lance Taylor

Post by Mark Mitchell
All we should be trying to do at this stage is get to a new VCS that
is no worse than CVS on the axes we care about. I can't see any
fundamental reason that we couldn't go back and add history later, if
that's compelling and someone wants to do it. The same goes for file
rename information: we're getting by without that now, and we can add
it in later if need be.

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.

Post by Ian Lance Taylor
Once you've created revisions in which files are not renamed, can you
really insert the file renames?

Only by dumping and reloading.

Post by Ian Lance Taylor
I don't think that would be would
minor hacking; I think it would be major surgery on the revision
control data.
Getting the old history in now, on the other hand, is minor hacking.
I'm perfectly willing to do some work to get it to happen.

Go for it :)
I'm happy to make test repos out of it.
(or you can grab cvs2svn and do it)

Post by Ian Lance Taylor
If I am wrong, and it can easily be done later, I would be happy to
hear it.
Ian

[Florian Weimer]

Post by Daniel Berlin

Post by Ian Lance Taylor
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 lists, and so on ("this was fixed in
r16432").

Post by Daniel Berlin

Post by Ian Lance Taylor
Once you've created revisions in which files are not renamed, can you
really insert the file renames?

Only by dumping and reloading.

This should be possible without revision numbers, though.

[Mark Mitchell]

Post by Ian Lance Taylor

Post by Mark Mitchell
All we should be trying to do at this stage is get to a new VCS that
is no worse than CVS on the axes we care about. I can't see any
fundamental reason that we couldn't go back and add history later, if
that's compelling and someone wants to do it. The same goes for file
rename information: we're getting by without that now, and we can add
it in later if need be.

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?
Once you've created revisions in which files are not renamed, can you
really insert the file renames? I don't think that would be would
minor hacking; I think it would be major surgery on the revision
control data.

We'd recreate the repository, just like we're doing now. I understand
that's got collateral impact on people who have their mirrored versions
of the repository, etc., but I just don't see that as a big deal.

Post by Ian Lance Taylor
Getting the old history in now, on the other hand, is minor hacking.
I'm perfectly willing to do some work to get it to happen.

If you make it happen, that's fine by me. I don't see anything wrong
with having old history. I just don't think it should in any way be a
gating factor.

[Marcin Dalecki]

Post by Mark Mitchell
I think all we should be doing is making sure that the new system is
at least as reliable as CVS, easy enough to use, faster for key
operations, and provides good infrastructure for getting things like
file renaming handled correctly going forward.

OK right until now I was just using subversion on Linux for some toy
projects.
At least some moron at some distro vendor already did package it for me.

Now I have tried it out on MacOSX, which is nowadays my main platform
for anything
not embedded.

Wanted to use svn on it. First I went the supposedly easy binary way.
Well the http site itself brags something about fink distribution for
MacOSX. No way!
I'm not going to replace my fine system utility set with something that
isn't technically
necessary... Thanks. I happen to have no big deal problem with MacOSX
as it is...

Alternatively they pointed me to some package at some ominous internet
service
provider which seemed like a native Mac OS X package. A quick check for
the readme
turned my away in pure disgust - it was "client only" and creeping some
Java stuff in.
Java - I don't want it near any of my basic tools. Sorry I'm just too
lazy to go out
to by another gig of RAM. SVN itself was shattered in a bunch of
dynamic libraries. A
single one for development I could understand but apparently they think
that since it's
easy to create them you have to use them. No thanks! Hell is it a that
bad idea to make
applications self containing? Disgusting... (but typical nowadays).

Thus I went the "do it yourself" way. I have an /opt hierarchy on my
Mac OS X boxes
which I maintain by RPM, just to keep the stuff away from native
directories and to
have the packages moderately compatible in setup between the different
OS-es I use.
(Linux, cygwin, Solaris, FreeBSD, Mac OS X that is).

And here the uphill bottle started:

subversion requires the apache runtime. No problem I got APR. The apr -
well this
beast is giving you a hell lot of trouble. I don't want to have the
usual dynamic library
proliferation. I don't want to have to worry about them. I prefer to
spend my time on
more interesting things that managing the system. But apparently for
some no sane reason
the configure script didn't honor --disable-shared. Shrug. Poor quality
sign.. Then I had
to discover that subversion needs apr-util - whatever it may contain.
apr-util wants expat
gdmb ldap and about 10 other subsystems I didn't care to count. Sorry
but I like to know what thoes are supposed to be for? OK welcome to the
modern "free software hell". You won't
one thing - you get 100 other things to install before you can even try
to use it.
Fortunately it was possible to compile this thing with some tweaks.
However most of the
dependencies couldn't be specified. The thing just went on to look for
them no matter what I told it. Didn't find much of the things already
present in the OS. That much about a reproductible setup... Down the
bin it is.

subversion setup itself was no better. mod_apache_blah/perl/python/ruby
and what a not...
Wonderfull I was only missing a requirement on PHP and VisualBasic. But
I just want to have
a source code management system.

Finally of course I was able to resolve those problems. But the
questions remain:

1. What do I have? Which *kind* of subversion do I have? Checkouts seem
to work
but which "feature" do I miss?

2. Can I just move the executable to a different box? Which hidden
setup dependencies
does it include?

3. Which "important" feature do I miss in my subversion?

4. Aborting a checkout didn't work properly. The thing didn't notice I
plugged the
network connection.

5. The client didn't handle signals properly (^C). It was trying for
ever to finish a
transaction it should abort.

6. Seeing problems 4. and 5. in the client I don't even want to have a
look at the
server - I already know up front that there will be enough problems
with it.

7. There seemed to be no compression mode for the checkout.

Anyway as a summary - down it to the bin:

There is no such a thing as subversion - there is a bunch of very
different applications
compiled from the same source code out there posing as a single one.

Maybe I'm getting old but this kind of library or scripting language
creep is something
that in my experience is always giving me a big warning about overall
design quality.
If a thing, which should serve just one purpose, namely source code
managment, is
showing that it tries to be everything to everybody, then the red alarm
lamp goes on for
me. With that much dependencies on particular external things there is
a guarantee that
this kind of software can't have any quality assurance - because there
are too many
variations you would have to test. Why do we use C after all? Mainly
because it doesn't
change. But whom I'm telling thins.

And experience shows that such a beast is very likely to give you over
time a lot of the
typical software deployment problems consultants make a living from.
Just look at the ToDo
list they have. It's certain that over the long time line they will be
happy implementing
bazilions of things suddenly releasing some kind of subversion 2.0 and
then finally
abondoning the 1.1.x half done series with the requirement to use some
crafted at the late
our perl script for repository migration, which is in reality only
working for the "hello
world" project, to the shiny new subversion 2.0. Seen that done that.
But I think the
problems of CVS don't justify taking such burdens and risks. However
it's very likely that
this kind of source code base will simply stop developing in a not too
long time frame - no
developer will be capable to even moderately test out any king of
changes to it very soon.

Thus I don't recommend changing repositories: subversion isn't going to
be better
then CVS over a medium time frame. It is just going to be less stable
secure and giving you
much more trouble if working in an environment different from the JBLD
(Joe's Bloated Linux
Distro).

Better stick with CVS - at least the problems are known and there are
no new problems
to occur over the long term. Testing SVN out right now may turn out
positive but for GCC
I think you have to think in decades and I seriously doubt that over
the longer time frame
subversion will "take over the world".

Just my 2c for whatever it may be worth. This list seems to be a gang
of "old boys" anyway,
so please excuse me if I was sounding like "preaching to the chorus"...
If you feel offended please excuse me bothering your time and ignore
it.

[Daniel Berlin]

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 have that set to require manual
intervention

Again, this has no effect when used against our server, so feel free to
kill whatever processes you like.

[Joseph S. Myers]

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 changed file - svn log appears to receive logs
from the server in uncompressed form, which can be large for logs of e.g.
the whole gcc/ directory. I'm sure those people developing GCC on dialup
would be glad of compression even for much smaller logs.

[Daniel Berlin]

Post by Joseph S. Myers

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 changed file - svn log appears to receive logs
from the server in uncompressed form,

This is true. However, you are talking about reporting data, and he was
asking about checkout of actual things in the repository.
:)

Post by Joseph S. Myers
which can be large for logs of e.g.
the whole gcc/ directory. I'm sure those people developing GCC on dialup
would be glad of compression even for much smaller logs.

In this case it may be best to just offer anonymous ssh with
compression, the way other people do (however, rather than have a key
that everyone installs, you just have an anonssh password).

However, i will explore making it use zlib to send logs when possible
anyway (this should be able to be implemented in a backwards compatible
manner because of how the protocol works).

[Marcin Dalecki]

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 client the server or
what else
ot of it. configure --help didn't tell anything about it.

These are java bindings, if you don't use them, don't use them.

They are there. They have to be supported maintained and so on... they
may break things if I suddenly update something on the system...
And don't tell me this isn't going to happen. I did already enough
oracle
installations in my life to get always nervous if I hear the word
Java...

Uh, you could simply build it with --disable-shared if you really
wanted

No this certainly didn't work. It was still building the shared stuff.

Post by Marcin Dalecki
No problem I got APR. The apr -
Fortunately it was possible to compile this thing with some tweaks.

With some tweaks?
It should compile out of the box on osx. I've done it before.

The emphasis is on should...

Post by Marcin Dalecki
However most of the
dependencies couldn't be specified. The thing just went on to look for
them no matter what I told it.

Having built apr many many times, i've never seen this problem.

So look closer... Try disabling ldap: --without-ldap will give you a
link
error for the library named well: "no".

Post by Marcin Dalecki
Didn't find much of the things already
present in the OS. That much about a reproductible setup... Down the
bin it is.
subversion setup itself was no better.
mod_apache_blah/perl/python/ruby
and what a not...

It requires none of these things, it simply checks fo them, and will
build bindings if you like.

So I would like to be able to disable stuff I don't need. Nothing there
- no
chance of something to be broken. (The perfect error free code - the
null code
doing nothing!)

Post by Marcin Dalecki
Finally of course I was able to resolve those problems. But the
1. What do I have? Which *kind* of subversion do I have? Checkouts seem
to work
but which "feature" do I miss?

In the end, you have the same thing you would have gotten from a client
install.

No I like to know what I get. I like to know what the application
contains
what it is supporting and so on. This can't be established for a naive
compile
relying on configure scripts which have broken --disable-xxx or
--without-xxx directives.
Call me pedantic. But this is what you get too if working long enough
in security
sensitive environments. Maybe I'm not the windows generation which
didn't grow up
with the impression imposed on them that crashing software is something
ethernal
to life...

What do you mean?
You can happily abort a checkout and restart it later through hitting
ctrl-c.

And now imagine you don't have an 1G connection working 24/7. Just
start the
command and plug the LAN from you computer and watch svn never noticing
this.
Press ctrl-c and watch svn never timing out... Good test for poorly
written
software btw.

Post by Marcin Dalecki
5. The client didn't handle signals properly (^C). It was trying for
ever to finish a
transaction it should abort.

For the database based server backend (not the filesystem based one),

A ha! There are multiple application which are posing as
subversion-server. So what is
a subversion server? Which "backend" did I get during the configure
process? Which backends did I get I never wanted to have? Wondering why
this makes me nervous? Well maybe I did already see too much CERT
anouncments in
my life...

the stupid database library will require aborting the transaction if
you
an abort a transaction, even if it is a readonly one, So it will only
let you abort an operation at certain times. Against our server, it
doesn't matter, so you can control-z and kill it.
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

A ha! Apparently the word transaction wasn't in the dictionary out
there?
Again poor quality for a new design. If a backend isn't as "secure" as
another
and could cause things to break or even work differently. Well it
shouldn't
be a back-end in first place at all.

Post by Marcin Dalecki
6. Seeing problems 4. and 5. in the client I don't even want to have a
look at the
server - I already know up front that there will be enough problems
with it.

You just provided "internals" information which tells me that the
speculation
was right.

Post by Marcin Dalecki
There is no such a thing as subversion - there is a bunch of very
different applications
compiled from the same source code out there posing as a single one.

What are you talking about?

I am talking about the fact that it wasn't possible to control the
feature set
of this application. Thus you have a single source base which you can
use to compile very different multiple applications. But you have a
single
application at hand.

You didn't want to install perfectly working binaries, then you
complain
that the source has dependencies! Of course it does. So does gcc.

No I have no problems with the dependencies I have a problem with:

1. The number of them.
2. The feature disease exposed by them.
3. The fact I couldn't *controll* them during software setup in an
aceptable way.

Every program has optional things (in this case, subversion's apache

False. The null program without any features has no optional things
(QED).

server module, database backend, and scripting langauge bindings) that
only are turned on if you have them.

That is an opinion but not a fact statement based on too much
time spend in front of a linux distribution. Usually it's very well
defined
what an oracle DB or a C99 compiler for example is. There are whole
organizations
doing just this - defining what things are meant to be...

Oh no, the configure script went looking to see if it could use already
installed libraries!

No it was using this information to enable and disable features.
Features I didn't want to have. Features I wanted to have control over.

You complain you don't want the server mode, but then complain that you
are missing these features.

No I complain that I get those features without the ability to CONTROL
whatever
I want them or not.

You hate shared libraries, and subversion has shared libraries.

I don't hate them! Don't put me words in the mouth.
But yes I just see too much software using them just out of
a sudden without good measure whatever it makes technically sense or
not.
This is always a hint for the fact that the person in question didn't
have sufficient competence to even know about the trade offs involved in
something as trivial as such an simple decision. Why should I then
assume he will
be competent in areas more demanding?

etc
Nothing in the rest of your message really has to do with subversion,
Just a rant about how you think about software development models.

Yes and I came to the conclusion that subversion isn't an example of a
good well developed product sufficiently well done to be good enough
base for something as endurable as the GCC. Yours millage may vary.
Basically I was warning here that the usability test isn't the
only thing you have to assess before taking decisions about something
like
a source code management system to be used. And well I permitted myself
to
give a cast on the darker corners of it.

Subversion has a very strict development process in terms of when
compatibly will and will not be broken.Even moreso than gcc, which has

I don't rely on promises. I rely on what I see, because I suffered
already
enough from those promises...

broken C++/libstdc++ compatibility at some level with every single
release.

So what? It wasn't a nice experience then. Would it be good for the
repository now?

CVS has done this as well over a number of releases.

The last time it did is already very very long ago... I think
it was years before subversion even existed.

It's also obvious you didn't bother to go looking at how they actually
develop it before ranting.

Look something has to be good in every piece to be good overall. But
it's
sufficient to be killed once to be dead.

[Daniel Berlin]

Post by Marcin Dalecki

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 client the server or
what else
ot of it. configure --help didn't tell anything about it.

These are java bindings, if you don't use them, don't use them.

They are there. They have to be supported maintained and so on... they
may break things if I suddenly update something on the system...

Whatever.
Forget it, i'm not even going to bother responding to your message.
It reads like one large troll.

[Daniel Berlin]

Against my better judgement, i'll respond anyway.

Post by Marcin Dalecki

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 client the server or
what else
ot of it. configure --help didn't tell anything about it.

The configure script prints out copious messages about what it is going
to disable because of what dependencies, so you are either not paying
attention, or again, you are trolling.

Post by Marcin Dalecki

These are java bindings, if you don't use them, don't use them.

They are there. They have to be supported maintained and so on... they
may break things if I suddenly update something on the system...
And don't tell me this isn't going to happen. I did already enough
oracle
installations in my life to get always nervous if I hear the word
Java...

So disable them if you are really worried about it.
Most people want them, so it's included by default if possible.
This is true of all the features you detest.

Post by Marcin Dalecki

Uh, you could simply build it with --disable-shared if you really
wanted

No this certainly didn't work. It was still building the shared stuff.

You need to be more specific.
No it isn't.
It still builds the libraries, but they are static. The libraries that
are necessary are built.

Post by Marcin Dalecki

Post by Marcin Dalecki
No problem I got APR. The apr -
Fortunately it was possible to compile this thing with some tweaks.

With some tweaks?
It should compile out of the box on osx. I've done it before.

The emphasis is on should...

It does.
If it does not, you need to report a bug against apr, including all of
your details.
I'm sure they will be glad to fix it.

Post by Marcin Dalecki

Post by Marcin Dalecki
However most of the
dependencies couldn't be specified. The thing just went on to look for
them no matter what I told it.

Having built apr many many times, i've never seen this problem.

So look closer... Try disabling ldap: --without-ldap will give you a
link
error for the library named well: "no".

Please file a bug against apr.

Post by Marcin Dalecki

Post by Marcin Dalecki
Didn't find much of the things already
present in the OS. That much about a reproductible setup... Down the
bin it is.
subversion setup itself was no better.
mod_apache_blah/perl/python/ruby
and what a not...

It requires none of these things, it simply checks fo them, and will
build bindings if you like.

So I would like to be able to disable stuff I don't need. Nothing there
- no
chance of something to be broken. (The perfect error free code - the
null code
doing nothing!)

So disable them.
It tells you what happens!
The configure --help will also tell you, contary to your claims
otherwise.

Post by Marcin Dalecki

Post by Marcin Dalecki
Finally of course I was able to resolve those problems. But the
1. What do I have? Which *kind* of subversion do I have? Checkouts seem
to work
but which "feature" do I miss?

In the end, you have the same thing you would have gotten from a client
install.

No I like to know what I get. I like to know what the application
contains
what it is supporting and so on. This can't be established for a naive
compile
relying on configure scripts which have broken --disable-xxx or
--without-xxx directives.

If you have discovered a broken directive, please report a bug against
the approriate configure script.

Post by Marcin Dalecki
Call me pedantic. But this is what you get too if working long enough
in security
sensitive environments. Maybe I'm not the windows generation which
didn't grow up
with the impression imposed on them that crashing software is something
ethernal
to life...

What do you mean?
You can happily abort a checkout and restart it later through hitting
ctrl-c.

And now imagine you don't have an 1G connection working 24/7. Just
start the
command and plug the LAN from you computer and watch svn never noticing
this.
Press ctrl-c and watch svn never timing out... Good test for poorly
written
software btw.

Post by Marcin Dalecki
5. The client didn't handle signals properly (^C). It was trying for
ever to finish a
transaction it should abort.

For the database based server backend (not the filesystem based one),

A ha! There are multiple application which are posing as
subversion-server. So what is
a subversion server?

Anything that speaks any of the protocols subversion clients speak, the
same way a cvs server is anything that speaks any of the protocols cvs
clients speak.

Post by Marcin Dalecki
Which "backend" did I get during the configure
process? Which backends did I get I never wanted to have? Wondering why
this makes me nervous? Well maybe I did already see too much CERT
anouncments in
my life...

Hey, maybe if you bothered to read what it said when you configured, or
you bothered to read the manual to see what the default is, you'd know.
Anyway, if you configure without berkeley db support, it will print:


You don't seem to have Berkeley DB version $db_version or newer
installed and linked to APR-UTIL. We have created Makefiles which
will build without the Berkeley DB back-end; your repositories will
use FSFS as the default back-end. You can find the latest version of
Berkeley DB here:
http://www.sleepycat.com/download/index.shtml
" >&5
echo "$as_me: WARNING: we have configured without BDB filesystem support


You don't seem to have Berkeley DB version $db_version or newer
installed and linked to APR-UTIL. We have created Makefiles which
will build without the Berkeley DB back-end; your repositories will
use FSFS as the default back-end. You can find the latest version of
Berkeley DB here:
http://www.sleepycat.com/download/index.shtml

Note that it tells you exactly what the default back-end is in case the
normal default (which is covered in the manual), is not available.

Post by Marcin Dalecki
A ha! Apparently the word transaction wasn't in the dictionary out
there?

Yes, well, this is external software. I make no qualms about saying
that berkeley db has had its problems.

Post by Marcin Dalecki
Again poor quality for a new design. If a backend isn't as "secure" as
another
and could cause things to break or even work differently. Well it
shouldn't
be a back-end in first place at all.

blah blah, hindsight is 20-20.
Also, the FAQ goes over why bdb was ever a choice.

You can come up with a large list of complaints about configuring cvs,
configuring gcc, etc.

Post by Marcin Dalecki
I am talking about the fact that it wasn't possible to control the
feature set
of this application.

Yes it is, through configure options. If they don't work, FILE BUGS!

Post by Marcin Dalecki
That is an opinion but not a fact statement based on too much
time spend in front of a linux distribution. Usually it's very well
defined

You have absolutely no clue what i develop on, and you are just trolling
again, Martin.

Post by Marcin Dalecki
what an oracle DB or a C99 compiler for example is. There are whole
organizations
doing just this - defining what things are meant to be...

Oh no, the configure script went looking to see if it could use already
installed libraries!

No it was using this information to enable and disable features.

Yes, of course, just like every other these days, *including the one we
are on the development list for* It will disable or enable various
assembler optimizations and debug output optimizations based on
configure tests. It also disables or enables other features based on
configure tests. Some of these you can't override, even if you want to!
You may not like this, but this is what the majority of users want.

All i have heard from you is a bag of complaints that you don't want
subversion to be developed the way it is, you want to be able to define
the exact feature set of every application, and one bug in a configure
script.

My basic answers are
1. Sorry, it's their choice to develop it how they want, and to be
perfectly honest, it's a great product. You could come up with the same
number and set of complaints about featuritis or whatever you have
against cvs, monotone, arch, and every other vcs out there. None are
perfect.
Your claims of poor quality are just opinion, and do not look very
informed, at least from my standpoint.

2. You are a dying breed, and are unlikely to be able to maintain your
control for very long. Your best chance is gentoo linux, which will let
you try to configure oyur apps exactly how you like, but you probably
don't like linux anyway, because you believe it's development
methodologies will invariably lead it to failure.
3. File a bug report against apr, and i'm sure they will be happy to
help you make --without-ldap work.

I'm not sure what tweaking you think was required for apr.
./configure --prefix=whatever
<make, make install>
on osx, worked fine on 10.3.7 and 10.4 with absolutely nothing but the
os and developer tools installed.
Andrew Pinski has also confirmed that he built it with no problems.

--Dan
PS never try to build openoffice, you'll have an aneurysm

[Marcin Dalecki]

Post by Daniel Berlin
Against my better judgement, i'll respond anyway.

Post by Marcin Dalecki

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 client the server or
what else
ot of it. configure --help didn't tell anything about it.

The configure script prints out copious messages about what it is going
to disable because of what dependencies, so you are either not paying
attention, or again, you are trolling.

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 it should within itself thus making
it self
containing - which is indeed fine. Much much better then autogen.
Thumbs up!

Contrary to the origingal apr-1.1.0.tar.bz2 the configure scripts inside
subversion honor --disable-shared and other flags properly.
If not linking against shared apr the subversion configure script
suddenly starts
to honour --disable-shared itself... OK. that explains my previous
problems.

The only thing which makes me still a bit nervous is that apr-0.9.5
seems a bit
of way off behind apr-1.1.0. However there seem to be no serious sec.
advisories for
apr versions newer then 0.9.4 out there...

[Kevin Puetz]

Post by Marcin Dalecki
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 it should within itself thus making
it self
containing - which is indeed fine. Much much better then autogen.
Thumbs up!

Indeed, taking a distro template (which quite understandably arranges for
everything possible to be packaged as external dependencies) is the wrong
approach if you want a self-contained build :-)

Post by Marcin Dalecki
Contrary to the origingal apr-1.1.0.tar.bz2 the configure scripts inside
subversion honor --disable-shared and other flags properly.
If not linking against shared apr the subversion configure script
suddenly starts
to honour --disable-shared itself... OK. that explains my previous
problems.
The only thing which makes me still a bit nervous is that apr-0.9.5
seems a bit
of way off behind apr-1.1.0. However there seem to be no serious sec.
advisories for
apr versions newer then 0.9.4 out there...

This is due to svn's binary compatibility policy. svn is somewhat unusual in
that it provides and public library API's (including language bindings,
hence the plethora of optional java/perl/python/etc dependencies), as well
as the commandline tools. This frees alternate frontends like svk, plugins
to integrate into IDEs, web frontends, and other such additions from
needing to constantly chase changes to the core.

Since apr 1.x is a new soname from apr 0.9.x, with incompatible ABI changes,
svn is therefore not permitted (by their own rules) to migrate until they
too change major version numbers. Anyway, thus far both branches of apr are
maintained (apache httpd 2.0 is also still using libapr0, so I don't think
there's much risk of neglect just yet). The latest apr 0.9.x release is
only 3 days old, so it's not like this is an old and abandoned branch...

[Richard Kenner]

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 than
they use for GCC development. You can't always assume that binaries are
available for every machine in question.

I was concerned about the difficulty in building svn and must say that I
wasn't at all encouraged by this report.

[Andrew Pinski]

Post by Richard Kenner
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 than
they use for GCC development. You can't always assume that binaries are
available for every machine in question.
I was concerned about the difficulty in building svn and must say that I
wasn't at all encouraged by this report.

I think this report was misleading. I just did a build with no options
to svn
on powerpc-darwin (aka Mac OS X) and I had troubles.

-- Pinski

[Daniel Berlin]

Post by Richard Kenner

Post by Richard Kenner
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.

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.
(He neglected to mention that it tells you what to get and where to get
it, including urls, of course)

He's also just flat out not reading.
He complains it doesn't tell him what he's missing, giving the example
of the database backend.
However, the configure script contains this, and removing bdb libraries
prints this message:

You don't seem to have Berkeley DB version $db_version or newer
installed and linked to APR-UTIL. We have created Makefiles which
will build without the Berkeley DB back-end; your repositories will
use FSFS as the default back-end. You can find the latest version of
Berkeley DB here:
http://www.sleepycat.com/download/index.shtml


When it detects a missing apr, which is a requirement, it prints:

echo "The Apache Portable Runtime (APR) library cannot be found."
echo "Please install APR on this system and supply the appropriate"
echo "--with-apr option to 'configure'"
echo ""
echo "or"
echo ""
echo "get it with SVN and put it in a subdirectory of this source:"
echo ""
echo " svn co \\"
echo " http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x \\"
echo " apr"
echo ""
echo "Run that right here in the top level of the Subversion tree,"
echo "then run autogen.sh again."
echo ""
echo "Whichever of the above you do, you probably need to do"
echo "something similar for apr-util, either providing both"
echo "--with-apr and --with-apr-util to 'configure', or"
echo "getting both from SVN with:"
echo ""
echo " svn co \\"
echo " http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x
\\"
echo " apr-util"
echo ""

How absolutely unfriendly!
It told you where you can check it out, and exactly what to do when you
got it!

Post by Richard Kenner
Plus, some

Post by Richard Kenner
people may use NFS and do filesystem stuff on a different machine than
they use for GCC development. You can't always assume that binaries are
available for every machine in question.

I wasn't. I was simply stating that if one is going to complain about
having to get source to build from source, one is in the wrong business.
Because every user program depends on some library or another.
This one tlels you what the libraries are and where to get them, without
having to google around to find the real source.

Post by Richard Kenner

Post by Richard Kenner
I was concerned about the difficulty in building svn and must say that I
wasn't at all encouraged by this report.

I think this report was misleading. I just did a build with no options
to svn
on powerpc-darwin (aka Mac OS X) and I had troubles.

I also have built svn on an osx machine with *nothing* but the developer
tools installed, with absolutely no trouble.
I know David has built it on aix.
Anyone is free to try and build it on the platform they use to develop
gcc.
If it does not work, please, let me know.

Kenner, before you complain about difficulties building it, you should
probably try building it.
If you run into trouble, please feel free to also complain on the
subversion/apr/whatever mailing list, and i'm sure they'll be happy to
fix their source if it's broken or not working.

[Marcin Dalecki]

Post by Daniel Berlin
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't need
and
because there is no application on my system needing them,
I was complaining about the inability to control whatever I get those
features
sucked in or not.

Post by Daniel Berlin
(He neglected to mention that it tells you what to get and where to get
it, including urls, of course)

Because I didn't complain about this at all.

Post by Daniel Berlin
He's also just flat out not reading.
He complains it doesn't tell him what he's missing, giving the example
of the database backend.

No! I'm complaining that it doesn't allow me to control what feature
set I get.
And I was complaining about the number of artificial dependencies the
system
is introducing.

Post by Daniel Berlin
I wasn't. I was simply stating that if one is going to complain about
having to get source to build from source, one is in the wrong
business.

Where did I say that?

Post by Daniel Berlin
Because every user program depends on some library or another.

Which is of course false.

Post by Daniel Berlin
This one tlels you what the libraries are and where to get them, without
having to google around to find the real source.

This wasn't the problem. Again the problem was how to control the
feature set
during the source code setup stage.

Post by Daniel Berlin
I also have built svn on an osx machine with *nothing* but the
developer
tools installed, with absolutely no trouble.

And you didn't have control about the features it contains.
You didn't mention that it needs apr and apr-util *installed* at
least...

[Daniel Berlin]

Post by Marcin Dalecki

Post by Daniel Berlin
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't need

And at the same time, providing things it does need, hence the
requirement.
It relies on it for portable file i/o and such (particularly across unix
and win32).

Post by Marcin Dalecki

Post by Daniel Berlin
Because every user program depends on some library or another.

Which is of course false.

Whatever.
Everything in /usr/bin and /usr/sbin on my osx box, my windows machine,
my linux machine, and the aix box appear to be linked against shared
library.

If you want to lawyer me, don't bother.
I've got a JD, i'm taking the bar exam in 11 days.
I'm not going for absolute precision in everything i say on the gcc
development mailing list, as most normal human beings do not when they
write.

I'm not talking to you giving you a very precise opinion of law, i'm
generalizing about the state of user programs.

So feel free to replace "every user program" with "vast majority of
useful user programs" like everyone else who read the email did.

--Dan

[Daniel Berlin]

Post by Daniel Berlin

Post by Marcin Dalecki

Post by Daniel Berlin
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't need

And at the same time, providing things it does need, hence the
requirement.
It relies on it for portable file i/o and such (particularly across unix
and win32).

Here, and before you try to interpret this as saying it only saying it
uses it only for portable file i/o (including portable file status,
deletion, opening, closing, determining stdin/stdout, unique files,
permissions, reading, writing, path encoding and decoding, etc), it also
very heavily uses it for the portable memory pool, portable dso loading,

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.

--Dan

[Marcin Dalecki]

Post by Daniel Berlin
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.

Yes sure that's fine. Being misguided by a Linux distro vendor of
particular
prominence I didn't notice you integrated it in to subversion in the
proper
way. Sorry! One thing for sure apr does what it does in a way far
superior to the
historically "grown", well, libiberty.

[Mike Stump]

Post by Richard Kenner
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 do it for a few common
platforms. I need to do it for darwin, but have been putting it off,
as it requires slightly more than no work. I think I just want to file
a bug report against darwin to include it. :-)

[Daniel Berlin]

Post by Mike Stump

Post by Richard Kenner
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 do it for a few common
platforms. I need to do it for darwin, but have been putting it off,
as it requires slightly more than no work. I think I just want to file
a bug report against darwin to include it. :-)

Andrew pinski has reported there is on problem compiling it on darwin
out of the box.

[Paul Schlie]

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 viewer? Is one
planned to be available in the timeframe being considered for gcc use?

- would the intend be to pull the entire unified tree (i.e. binutils, etc.)
under svn? If not, might that create some potential complications?

- is the svn client sw known to be cleanly build-able, reasonably robust.
and secure on all likely significant client platforms?

(just curious, as it wasn't obvious after some basic research?)

[Daniel Berlin]

Post by Paul Schlie
Out of curiosity, although svn certainly seems attractive, are there any
- 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 1.
Whatever gave you this idea?

Post by Paul Schlie
Has svn ever been relied upon for a significant open source project?

Yes, Mono, all of the apache projects, SpamAssassin, etc.

Post by Paul Schlie
- there doesn't seem to be an analogous svn web-based viewer?

There are many. The one that most people use as a cvs viewer, viewcvs,
supports svn already.

There is also websvn, chora, and a number of other svn repository
viewers.

This is not hard info to find, to be honest,
http://subversion.tigris.org/project_links.html
Under "repository browsing tools", lists the major ones.

Post by Paul Schlie
Is one
planned to be available in the timeframe being considered for gcc use?

Uh, if it wasn't, and they weren't already mature, we wouldn't be having
this discussion.

Post by Paul Schlie
- would the intend be to pull the entire unified tree (i.e. binutils, etc.)
under svn?

Not right now.

Post by Paul Schlie
If not, might that create some potential complications?

No more complications than currently exists.

Post by Paul Schlie
- is the svn client sw known to be cleanly build-able, reasonably robust.
and secure on all likely significant client platforms?

Yes.

[Paul Schlie]

Post by Daniel Berlin

Post by Paul Schlie
Out of curiosity, although svn certainly seems attractive, are there any
- 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 1.
Whatever gave you this idea?

- I apparently misinterpreted:

http://svn.collab.net/viewcvs/svn/trunk/

as was viewing it via viewcvs (which I now understand is svn friendly)

And thank for the remaining answers as well, -paul-

[Kai Henningsen]

Post by Paul Schlie
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 repository, and
/viewcvs/svn/... will access a SVN reporitory.

MfG Kai

[Kevin Puetz]

Post by Paul Schlie
Out of curiosity, although svn certainly seems attractive, are there any
- 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 somehow found the old historical tree (unsurprisingly,
at the time when svn converted to self-hosting there were no conversion
scripts for the old history in CVS like there are now).

Post by Paul Schlie
   Has svn ever been relied upon for a significant open source project?

There's a (partial, of course) list of projects now using svn on
http://subversion.tigris.org/propaganda.html - a few off the list are
apache, samba, mono, and cups.

Post by Paul Schlie
- there doesn't seem to be an analogous svn web-based viewer? Is one
   planned to be available in the timeframe being considered for gcc use?

viewcvs actually supports svn natively, and there are also svn-only
interfaces like trac, websvn, and probably some others too.

Post by Paul Schlie
- would the intend be to pull the entire unified tree (i.e. binutils, etc.)
   under svn? If not, might that create some potential complications?

It might fail to help clean them up, but as CVS provides no inter-file
relationships at all, I don't see how it's meaningfully worse. I haven't
any idea what plans are or aren't being ade.

Post by Paul Schlie
- is the svn client sw known to be cleanly build-able, reasonably robust.
   and secure on all likely significant client platforms?

the client and the fsfs server backend ought to be as portable as apr is (so
anyplace that apache can run). BDB has some additional requirements, but in
any case a client doesn't need either backend, just the working copy stuff.

Post by Paul Schlie
(just curious, as it wasn't obvious after some basic research?)

[Lars Segerlund]

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 to start would be www.tigris.org where svn is hosted, ( and also contains
all the other information you talk about ), the query on google was 'subversion
homepage'.

The main complaint on svn seem's to be a slow blame command, which is being worked
on and has some improvement in the next release, ( from the mailinglist ).

/ regards, Lars Segerlund.

On Thu, 10 Feb 2005 22:32:18 -0500

Post by Paul Schlie
Out of curiosity, although svn certainly seems attractive, are there any
- 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 viewer? Is one
planned to be available in the timeframe being considered for gcc use?
- would the intend be to pull the entire unified tree (i.e. binutils, etc.)
under svn? If not, might that create some potential complications?
- is the svn client sw known to be cleanly build-able, reasonably robust.
and secure on all likely significant client platforms?
(just curious, as it wasn't obvious after some basic research?)

[Richard Guenther]

Post by Daniel Berlin
(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
problems. The only thing I noticed is that a checked out HEAD is now
784MB instead
of 280MB with CVS. Is there a way to have "cheap" multiple
development trees, like
cp -Rl the whole thing and svn is still happy? I usually have about
10 gcc trees
lying around, half of them being "different" HEADs - and 8Gb instead
of 3Gb counts,
even in the days of el-cheapo disk-space.

Richard.

[Kevin Puetz]

Post by Richard Guenther

Post by Daniel Berlin
(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
problems. The only thing I noticed is that a checked out HEAD is now
784MB instead
of 280MB with CVS. Is there a way to have "cheap" multiple

This is because of the 'text-base' - svn keeps pristine copies of the
checked-out version locally, which makes diffing your local mods a local
operation (and correspondingly, makes it much faster), lets it send only
diffs on the network, lets 'svn status' ignore files that were touched but
not really modified, etc. There's a tradeoff in disk space, but it's
generally a good one in these heady days of 50¢/GB disk space :-)

Post by Richard Guenther
development trees, like
cp -Rl the whole thing and svn is still happy? I usually have about

You may want to pose this question on the svn list, but I don't see any
immediate reason that wouldn't work. svn is (as far as I know) using the
unlink()/rename() approach to ensure robustness, which should also make it
hardlink-friendly. The savings will tend to degrade over time though, since
doing svn up on each folder would break the linking for files in which it
receives modifications (even if each tree gets the same modifications) -
but I expect you knew that.

Post by Richard Guenther
10 gcc trees
lying around, half of them being "different" HEADs - and 8Gb instead
of 3Gb counts,
even in the days of el-cheapo disk-space.

You might also find a client like svk serves your needs better - as part of
supporting disconnected operation, it takes a different tack on this
matter. Instead of keeping a text-base in the working copy, it keeps a
local mirror of part or all of the repository (which can be partial in both
layout and time - 'only includes module/portion/*' and/or 'only includes
revisions N-HEAD'). This mirror of the repo can then be used to support
multiple working copies, each of which is then entirely pristine (svk even
keeps its admin data about what revisions are checked out to each WC
elsewhere, not in subfolders). And it can commit right back to the
upstream.

Post by Richard Guenther
Richard.

[Daniel Berlin]

Post by Daniel Berlin
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 answers (such as what the status flags mean, etc)

I thought I'd email this rather than put it on the mailing list, as
hopefully it's easy to get around (I can't use irc...)
I work on the libstdcxx_so_7-branch. This includes only a copy of the
libstdc++-v3 directory. As CVS is quite stupid about directories, on CVS
I could just check out gcc branch and the libstdc++-v3 from
libstdcxx_so_7 and pop the new libstdc++-v3 into gcc's directory and
everything would work fine(ish).
It's not clear to me what the best way of working with libstdcxx_so_7 is
going to be in svn. Any suggestions?

(i've copied this back to the mailing list, since it is probably useful
for others to know. I believe the svnhelp page on the wiki has this
info on it as well. Hopefully, you don't mind :P)

Easy enough.

svn co the trunk of gcc (svn co svn://svn.toolchain.org/svn/gcc co
trunk)
go to the libstdc++-v3 directory of the trunk.
type
"svn switch
svn://svn.toolchain.org/svn/gcc/branches/libstdcxx_so_7-branch/libstdc+
+-v3 ."

It will switch that part of your working copy to the libstdcxx_so_7
branch.

svn is happy to let you have working copies that are mixed from various
branches, and update will update each part of the working copy
approriately.

Thank you,
Chris

[Nathanael Nerode]

First of all, I totally approve of moving to Subversion.

Post by Daniel Berlin
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.

Post by Daniel Berlin
Find the current revision of the apple-ppc-branch using svn info on your
checked out copy.

Right, this gives the revision number for the apple-ppc-branch.

Post by Daniel Berlin
"svn merge -r<current rev that tells you>:HEAD
svn://svn.toolchain.org/svn/gcc/trunk "
That will merge in all the changes from the HEAD since the last time you
merged.

No, it won't. This compares the status of "trunk" between your branch
and HEAD. Is "trunk" on apple-ppc-branch going to contain the
trunk from the last time apple-ppc-branch was merged from trunk?
Why *would* it? (I suppose special procedures used during previous merges
could have had that effect, but that doesn't apply to converted-from-CVS
stuff.)

Obviously, for a brand-new branch, it would contain the branchpoint,
which is correct. For a branch which has had a merge from trunk already,
it will *not*. I'm looking at the docs for svn 1.1.3 here.
"Ideally, your version control system should prevent the double-application of
changes to a branch. It should automatically remember which changes a branch
has already received, and be able to list them for you. It should use this
information to help automate merges as much as possible.

"Unfortunately, Subversion is not such a system. Like CVS, Subversion does not
yet record any information about merge operations. When you commit local
modifications, the repository has no idea whether those changes came from
running svn merge, or from just hand-editing the files."

This is especially true of old merges being ported over from CVS.

In order to merge correctly, we need to know the last repository revision
number on trunk which was merged into the branch. This means, in the case of
an old merge done in CVS, the revision number corresponding to the last
mergepoint.

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

[Daniel Berlin]

Post by Nathanael Nerode
First of all, I totally approve of moving to Subversion.

Post by Daniel Berlin
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.

Post by Daniel Berlin
Find the current revision of the apple-ppc-branch using svn info on your
checked out copy.

Right, this gives the revision number for the apple-ppc-branch.

Post by Daniel Berlin
"svn merge -r<current rev that tells you>:HEAD
svn://svn.toolchain.org/svn/gcc/trunk "
That will merge in all the changes from the HEAD since the last time you
merged.

No, it won't. This compares the status of "trunk" between your branch
and HEAD. Is "trunk" on apple-ppc-branch going to contain the
trunk from the last time apple-ppc-branch was merged from trunk?
Why *would* it? (I suppose special procedures used during previous merges
could have had that effect, but that doesn't apply to converted-from-CVS
stuff.)
Obviously, for a brand-new branch, it would contain the branchpoint,
which is correct.

Yes, i was misthinking.
You are completely correct.
Answering 300 emails means i'm bound to give wrong answers
occasionally :)

I'll keep the last branchpoint of each branch for the initial import

Post by Nathanael Nerode
For a branch which has had a merge from trunk already,
it will *not*. I'm looking at the docs for svn 1.1.3 here.

It's plan for some point (and svk is starting to have a good hnadle on
it).

Post by Nathanael Nerode
(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 does the same thing using properties.

[Zack Weinberg]

Post by Daniel Berlin

Post by Nathanael Nerode
(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 does the same thing using properties.

Maybe the merge tags can be translated in the conversion to svnmerge's
properties? Then we can just all use svnmerge and be happy.

zw

[Daniel Berlin]

Post by Zack Weinberg

Post by Daniel Berlin

Post by Nathanael Nerode
(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 does the same thing using properties.

Maybe the merge tags can be translated in the conversion to svnmerge's
properties? Then we can just all use svnmerge and be happy.

This is almost possible. The problem is that you need to know what
other revisions were applied to the branch already, which is hard to
calculate.
:)

Thus, it's better to have people svnmerge init the branches for their
own branches if they want, since it lets you record what revisions were
already merged at init time through one of it's options.

Or you can solve the problem of trying to figure out which revisions we
already applied, and i'll happily throw the code in cvs2svn.

[Mike Stump]

Post by Daniel Berlin
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, treeprofiling, and then a random other (important)
branch uses the first for its merge.

Also, even if you could track those down (you can't), it still would
obliterate merge auditing, which is a very useful feature to find how
exactly how someone screwed up a past merge.


I don't see the advantage of wiping those labels yet.

If you left all labels mentioned in any log entry, that would almost
solve most instances that I know about, but, sometimes people misspell
the tags in obvious ways in the log messages.

[Daniel Berlin]

Post by Mike Stump

Post by Daniel Berlin
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, treeprofiling, and then a random other (important)
branch uses the first for its merge.
Also, even if you could track those down (you can't), it still would
obliterate merge auditing, which is a very useful feature to find how
exactly how someone screwed up a past merge.
I don't see the advantage of wiping those labels yet.
If you left all labels mentioned in any log entry, that would almost
solve most instances that I know about, but, sometimes people misspell
the tags in obvious ways in the log messages.

Fine, i'll just keep all the non-snapshot tags for now.

[Richard Earnshaw]

Post by Daniel Berlin

Post by Mike Stump

Post by Daniel Berlin
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, treeprofiling, and then a random other (important)
branch uses the first for its merge.
Also, even if you could track those down (you can't), it still would
obliterate merge auditing, which is a very useful feature to find how
exactly how someone screwed up a past merge.
I don't see the advantage of wiping those labels yet.
If you left all labels mentioned in any log entry, that would almost
solve most instances that I know about, but, sometimes people misspell
the tags in obvious ways in the log messages.

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. The
SVN book goes on about trunk, branch and tag top-level directories, but
there's no reason to stick to just those.

We could, for example have rel-branch and rel-tag directories for the
main releases and then keep branch and tag for development work (or we
could do it the other way around).

For the case above, we could have non-snapshot as the top-level
directory. The limit seems to be your ingenuity...

R.

[Mike Stump]

Post by Richard Earnshaw

Post by Daniel Berlin
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 versioned(?). I can't imagine that
the size of tags would matter, I think we should do that. We could
even move old tags to a directory called old if we wanted to, to help
sort out the chaff and reduce clutter while still allowing people doing
archeology to be able to easily find them. It seems safer to import
them all, and then remove them in the new system, as it seems to be
trivial to restore any mistakes, while, if they go missing in the
import, putting any tag back would be, uhm, hard.

[Daniel Berlin]

Post by Mike Stump

Post by Richard Earnshaw

Post by Daniel Berlin
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 versioned(?).

Yes.
Thus, your real problem is that if you look at older revisions of the
tags directory, it will be ugly as hell :)

Post by Mike Stump
I can't imagine that
the size of tags would matter, I think we should do that. We cou
even move old tags to a directory called old if we wanted to, to help
sort out the chaff and reduce clutter while still allowing people doing
archeology to be able to easily find them. It seems safer to import
them all, and then remove them in the new system, as it seems to be
trivial to restore any mistakes, while, if they go missing in the
import, putting any tag back would be, uhm, hard.

Also realize constructing all these tags makes conversion a lot slower
(it multiples the number of times we have to spawn "co" by a lot. Please
don't point out the obvious way of fixing this, but i don't really have
time right now to try to make a one time process much faster by not
spawning co a million times and instead enumerating the plaintexts into
a database)
If we really want all the tags, i have no plans to make them *all*
available before we switch. I have made the non-branch-point,
non-snapshot, non-merge ones available in the next version of the
converted repo, which is being uploaded.
This actually includes apple-gcc-<whatever>, since that wasn't cuaght by
my exclude regex.
:)

[Marcin Dalecki]

Post by Mike Stump

Post by Richard Earnshaw

Post by Daniel Berlin
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 versioned(?). I can't imagine that
the size of tags would matter, I think we should do that. We could
even move old tags to a directory called old if we wanted to, to help
sort out the chaff and reduce clutter while still allowing people
doing archeology to be able to easily find them. It seems safer to
import them all, and then remove them in the new system, as it seems
to be trivial to restore any mistakes, while, if they go missing in
the import, putting any tag back would be, uhm, hard.

Hmm... What about the "trivial" strategy of automatic commit mirroring
for a sufficient
long time? I guess old information deflates in value pretty fast (maybe
about one year?).
Could be easier to implement.

[Daniel Berlin]

Post by Marcin Dalecki

Post by Mike Stump

Post by Richard Earnshaw

Post by Daniel Berlin
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 versioned(?). I can't imagine that
the size of tags would matter, I think we should do that. We could
even move old tags to a directory called old if we wanted to, to help
sort out the chaff and reduce clutter while still allowing people
doing archeology to be able to easily find them. It seems safer to
import them all, and then remove them in the new system, as it seems
to be trivial to restore any mistakes, while, if they go missing in
the import, putting any tag back would be, uhm, hard.

Hmm... What about the "trivial" strategy of automatic commit mirroring
for a sufficient
long time? I guess old information deflates in value pretty fast (maybe
about one year?).
Could be easier to implement.

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

We did convresion this way with bugzilla and it worked okay. I just
translated the gnats database every so often.
The more important part is that people feel comfortable using the tool.
making the data all look right is the easy part :)

[Florian Weimer]

Post by 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 branches.

The CVS loginfo script is invoked with a list of files changed in that
commit. (I don't think that conversion should be done this way, but
it's still an option.)