Greg Hudson wrote:
> 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.
You are right, I originally was just going to post the patch but then
got carried away and forgot to change the subject line before sending.
> > 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).
Glad others are onto the same issue. My patch was designed to be the
minimum to get the job done and so adds less functionality. I had noticed
the postings referenced in svn_types.h were from 2001, so guessed that
maybe an interim solution is needed.
> 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.
Thanks, good point.. but is source or binary compatibility required?
If the former, then the patch would still work simply by putting the APR
array inside the svn_subst_keywords_t structure instead of replacing
that structure.
> > 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.
I was thinking more along the lines of a tool that didn't require
direct access to the repository.. E.g., imagine ProjectFoo wanted to
let any arbitrary person mirror their repository using only anonymous,
read-only client access. If such a tool existed, they would automatically
get this for free by granting the equivalent normal SVN access.
> It seems like one could write a novel-length conference paper on the
> trials and tribulations of converting CVS repositories. There are
It's clearly a complex issue -- more so than I originally imagined...
> > (+) 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.
True, and I didn't mean to imply that.. rather that if you write
it in C and you design it properly then you should end up with as
good performance as there is to be gotten...
> > 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
Thanks for the refs.
> 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.
That sounds like a reasonably intuitive usage model. I think this combined
with compression should satisfy most pepole who care about disk space.
> (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.)
I doubt this would be a problem -- at least, in the way I see things.
My mental model (which is why the existing behavior was surprising)
is that you do whatever you want to your working code to "get it
ready", i.e., move things aroud, add, modify, delete, etc. to your
heart's content. Then the commit operation is like taking a picture
of it and storing that in the repository. Until you take the picture,
everything is still "in flux"...
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 Sun Jun 13 22:18:57 2004