[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[PATCH] "simple" custom keywords implementation

From: Archie Cobbs <archie_at_dellroad.org>
Date: 2004-06-11 18:26:37 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.