Meta-comment: this is a high-traffic list, so accurate subjects are very
important. I ignored your message for a couple of days because the
topic wasn't of great interest to me. Had I realized it was a more
general post, I would have probably responded sooner.
On Fri, 2004-06-11 at 12:26, Archie Cobbs wrote:
> 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.
John Peacock has been working on this issue. See
http://subversion.tigris.org/issues/show_bug.cgi?id=890 for his work
(which I've been meaning to review).
One thing you missed in your patch is that we can't just change the
signature of API functions like svn_subst_build_keywords before svn 2.0,
which we hope is a long ways off. See "Release numbering,
compatibility, and deprecation" under HACKING.
> 1. cvsup
There are various implementations of this concept, such as the perl
svn-mirror. (I wish I could provide a comprehensive list, but I haven't
been following that work all that carefully.)
Fundamentally, it's pretty easy to cobble up by hand as well,
particularly if you can rely on post-1.0.x features:
* With svnadmin dump --deltas, you could make a directory of delta
dumps available for each repository revision. rsync that directory,
apply any new dumps, and you're done.
* With FSFS, you could just rsync the repository (perhaps configured
to ignore the db/transactions directory), because of the way it's laid
out.
> 2. Conversion from CVS -> SVN.
Karl has answered this section specifically. In general, I'd encourage
you to get involved in the cvs2svn project (which has separate mailing
lists, etc.).
It seems like one could write a novel-length conference paper on the
trials and tribulations of converting CVS repositories. There are
dozens of local-usage foibles (recognizing repository copies, as you
pointed out, is just one of them), and the lack of atomic commits or
versioned branch creation in CVS is tough to work around while still
taking a reasonable amount of time.
I've seen a variety of tools for doing CVS to foo conversion (vcp will
convert incrementally from CVS to various other things; monotone has a
built-in conversion facility), but many of them just punt on branches.
> (+) Written in C using the svn_xxx libraries for portability and
> efficiency. Conversion will be slow enough as it is.
It's not generally a good assumption that a slow problem will be
appreciably faster for being written in C. It depends on where the time
is spent.
> 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.
Agreed. We've known about interfering proxies all along, of course, but
I don't see a lot of documentation about the issue.
> 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.
http://subversion.tigris.org/issues/show_bug.cgi?id=525
http://subversion.tigris.org/issues/show_bug.cgi?id=908
In addition to these two ideas, it would also be possible to avoid most
of the text-base penalty if we had a read-only checkout mode, where you
had to "svn edit" a file before editing it. Then the text-base could be
created upon "svn edit". Such an option would be less convenient
(although it could be as simple as C-x C-q in emacs to svn edit a file),
but would also allow faster crawls for working copy changes.
Fundamentally, the main problem with any of these approaches is that
libsvn_wc isn't our best code, and it's hard to extend with confidence.
> 2. Suppose I do this:
>
> $ svn mv olddir newdir1
> $ svn mv newdir1 newdir2
http://subversion.tigris.org/issues/show_bug.cgi?id=756
In addition to our libsvn_wc travails, we also suffer here from thinking
of moves as "delete + add with history", making it more complicated
(though still possible) to get this sequence right.
(Also, we don't want to fool anyone into thinking that the internal
history is preserved in "svn mv a b; svn mv b c". So, even in a more
ideal world, we might require a --force on the second command.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jun 13 17:32:49 2004