Hello!
This is a long email, sorry, lots of pent up things to say :-)
I'm a recovering longtime habitual CVS and have recently become
an enthusiastic fan of SVN (we're using it now at work). SVN is
very well thought out and the code is very well organized. I am
eager to contribute (but have little free time these days...).
Anyway, here are some thoughts & questions from the perspective
of a recent convert...
The FreeBSD dream
-----------------
I've been a FreeBSD committer for a long time and am now dreaming
of the day when FreeBSD can switch from CVS to SVN. Not only will
this make life easier someday, but in the meantime it makes for an
interesting real world "thought experiment" for SVN. I.e., what
would it take to make SVN acceptable to FreeBSD?
In summary I think the challenge is not overcoming human intertia,
but rather ensuring that no current functionality would be lost
by switching over.
Others have thought about this too.. e.g. see this posting:
http://lists.freebsd.org/pipermail/freebsd-hackers/2004-February/005592.html
So to take a very small step in this direction, and as an initial
peace offering, I've attached a patch to add support for custom keywords.
This is far less ambitious than the ideas referenced in svn_types.h,
i.e., no internationalization, no new substitution strings, etc.
Basically this just allows you to have a keyword like "FreeBSD=Id"
which would cause $FreeBSD$ to act just like $Id$.
As a side benefit, this makes the internal handling of keywords a
bit more general (keyword substitutions are represented by an array
of keyword, replacement string pairs) so future changes and additions
can be made easier. E.g., FreeBSD likes to include the full repository
path in the $FreeBSD$ string rather than just the "base name" of
the file; something like "$PathId$" could be added by changing only
one function.
It also fixes this small bug (?): if svn:keywords contains a "short"
keyword but not a "long" one (or the reverse), then both the "short"
and "long" keywords will get substituted. E.g. $HeadURL$ will get
substituted in the file even if svn:keywords contains only "URL".
Now on to other future projects that would need to be tackled..
I see to major roadblocks.
1. cvsup: many FreeBSD users mirror the FreeBSD CVS repository locally.
It does not suffice to say "you don't need cvsup; just use a caching
proxy server" because (a) you can't take it with you (ie, go offline)
and (b) you can't have your own private branches off the FreeBSD code,
which a lot of people do; cvsup correctly handles the merges (for
the curious, you create your private branches using a high starting
branch number like 10000 which doesn't conflict with FreeBSD branches)).
I think a SVN cvsup equivalent that solved (a) and (b) would be easy
to write. I've already started planning it and would love to hear
anybody else's thoughts.
The usage for this program (let's call it "reposvnc") would be:
reposvnc [--path path] [--tag path] URL /path/to/repos
URL points to the remote repository; /path/to/repos is the local mirror.
--path would specify a subdirectory into which to mirror the remote
repo, defaulting to "/". In the local repo that directory would
have a "reposvnc:revision" property telling what remote revision
number it was synchronized up to; this would be read each time and
used to get only the incremental changes from the remote server.
Without --tag, it would simply mirror the repository, and if no
other commits are made to the local repository, all revision numbers
would correspond in both repositories. Even if they didn't, you could
reverse engineer them using the "reposvnc:revision" property history.
(Presumably local commits would be to a different subtree).
To more explicitly support having both remote and local commits to the
same repository (ie, case (b) above), where local commits would cause
the local and remote revision numbers to get out of sync (or if multiple
remote repos were mirrored to the same local repo), the --tag flag could
be used. This would cause an additional local subdirectory to be created
whose name was the remote repository revision number.
E.g., if "reposvnc --path /mirrors/freebsd --tag /mirrors/revisions/freebsd"
mirrored new revisions 1000, 1001, and 1002, then these new "tag"
subdirectories would get created:
/mirrors/revisions/freebsd/1000
/mirrors/revisions/freebsd/1001
/mirrors/revisions/freebsd/1002
(There is the issue of avoiding too many subdirectories, so we might
want to break things up into a mult-level namespace, but whatever).
Then it would be easy to merge in remote and local changes if you
had your own private version of the FreeBSD source tree.
Does this idea make sense at all to SVN veterans?
2. Conversion from CVS -> SVN. There are some reasonable tools out
there, but it's not clear exactly how they work, or how/if they
handle vendor branches, etc. What exists today is insufficient for
a project like FreeBSD where prior history is dear and loss of such
is unacceptable.
I'd like to see a conversion tool that has the following attributes:
(+) Written in C using the svn_xxx libraries for portability and
efficiency. Conversion will be slow enough as it is.
(+) It has a "theory of operation" behind it. This "theory of operation"
is complete and fully documented, so that someone can predict
deterministically exactly how any CVS repository will be converted.
(+) Ability to coalese individual CVS file commits that are part of the
same commit into a single SVN commit (like cvs2svn.py does).
(+) Fully parameterizable. E.g., if we consider all CVS commits that
happened within 5 seconds of each other that have the same commit
message as part of a single SVN commit, then the "5 seconds" should
be paramaterizable via command line flags.
(+) Configurable ability to map vendor branches into a local or
global subdirectory, etc. (How would this work exactly?)
(+) Configurable ability to map labeled CVS branches and tags into
user-defined subtrees, etc. (How would this work exactly?)
(+) Support for recognizing "repo copies". Often in FreeBSD a file
is moved, but the history is preserved by copying the actual RCS
file and changing all "FOOTAG" tags to "old-FOOTAG". The converter
should have the ability to hunt down all such files (at the cost of
slower operation).
What else on the "wish list" am I missing here?
Other random comments
---------------------
The idea that you can use the svn client anywhere you can make an
HTTP request is not entirely true. E.g., when I tried it at one place
of work this happened:
$ svn co http://svn.collab.net/repos/svn/trunk subversion
svn: REPORT request failed on '/repos/svn/!svn/vcc/default'
svn: REPORT of '/repos/svn/!svn/vcc/default': 400 Bad Request (http://svn.collab.net)
This particular place has an "invisible" Checkpoint (?) firewall/filter
for outgoing HTTP requests that doesn't understand the REPORT request,
although it had no problem with earlier PROPFIND requests. Perhaps this
should be added to the FAQ.
Bugs & Enhancement requests
---------------------------
The bug DB says "send an email first" so here it is.
1. This is not a new enhancement request but I didn't see it in the DB.
Having two copies of every file in your working space irks some people,
especially if you're working on a small piece of a huge tree. How
about adding the option to compress or omit the "base" copies? E.g.:
<entry name="foo.c" base-storage="gzip" ... />
Other possibilities for "base-storage" are "none", "bzip2".
Even "on-demand", which would be like "none" until you did some
explicit operation ("svn update-base" ?) to get the base copies
(this operation would use the timestamp and MD5 to determine if the
working copy of the file had changed and not access the server if it
had not). This would allow the developer greater control and the
ability to to create the base copies a "subtree at a time" without
contacting the server. Also, "svn clear-base" could remove the
base files to clear some disk space.
I.e.: give the user more control over managing working copy disk usage.
2. Suppose I do this:
$ svn mv olddir newdir1
$ svn mv newdir1 newdir2
svn: Use --force to override this restriction
svn: Move will not be attempted unless forced
svn: 'newdir1' has local modifications
$ svn mv --force newdir1 newdir2
svn: Not allowed to copy or move 'foo': it is not in the repository yet; try committing first
First "bug": I don't see why this restriction needs to exist. That is,
why can't subversion just convert my working state into whatever state
it would have ended up in had I just said "svn mv olddir newdir2" ?
Perhaps it could handle this case and convert it internally into a
revert followed by a move.
Cheers,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 11 18:51:09 2004