You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Archie Cobbs <ar...@dellroad.org> on 2004/06/11 16:26:37 UTC
[PATCH] "simple" custom keywords implementation
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
Re: [PATCH] "simple" custom keywords implementation
Posted by kf...@collab.net.
Archie Cobbs <ar...@dellroad.org> writes:
> What about untagged branches? Maybe they should just be elided, they
> are completely useless anyway. Or they could be given machine generated
> names and dumped into some untagged-branches/ directory.
The latter is what happens right now, yes.
> But I think it's worthwhile to do the thought experiment of asking what
> is the best we could feasibly do (putting aside for the moment the
> question of who's actually going to find time to write the code), because
> what you get from the conversion process is one of the most critical
> issues for a project like FreeBSD deciding to move to SVN.
I'm not so sure. Exploring that question reveals that the answer is
essentially infinitely deep... There are always N improvements
possible. You have to prune the tree of what you consider, for
sanity :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] "simple" custom keywords implementation
Posted by Archie Cobbs <ar...@dellroad.org>.
kfogel@collab.net wrote:
> > 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.
>
> What makes you think current tools (such as cvs2svn) lose any history?
I guess I don't .. though it's kindof hard to tell exactly what it does
from the documentation.
> Having it be clear exactly how they work is another matter.
> Conversion from CVS to SVN is inherently complex; to make it clear how
> a conversion works means describing something very complex. Certainly
> cvs2svn could be better documented (I don't know about the other
> converters), but it sounds like you're wishing for simplicity where
> none can ever be.
I'm not wishing for simplicity.. I agree the problem is inherently
complex (and I certainly don't understand all the subtle issues),
and therefore the solution must also be. But converting a repo
is a relatively rare operation, so "one time" complexity is fine.
However, the conversion must be "complete" in the eye of the user
(e.g., FreeBSD community). People must continue to be able to easily
get the same information from the repo that they used to could get.
So the question is (as you point out): what does "completeness" mean,
and is it even possible to define it, much less achieve it?
I'd be interested in discussing this.. certainly you've thought about
it more than me but I'm curious to get up to speed..
It's clear that you can create a top level subdirectory somewhere
for each tag (branch or revision). But in practice, there are
"global" and "local" tags; the latter are restricted to some subtree.
E.g. in FreeBSD's contrib/ directory where imports of tcpdump, bind,
etc. live. Each release of tcpdump is tagged upon import, etc. Perhaps
there should be tags/ and branches/ subdirectories created at those
levels, etc. This is something that could be manually specified, or
possibly auto-detected by finding the smallest subtree that completely
"contains" the tag.
What about vendor branches? Presumably they can be treated just like
any other branches.
What about untagged branches? Maybe they should just be elided, they
are completely useless anyway. Or they could be given machine generated
names and dumped into some untagged-branches/ directory.
> Your converter wish list is great, I just think it's asking for the
> moon :-). The problem is very, very, very, very, very hard. Just to
> get it to work "correctly" at all is hard. Any enhancement beyond
> that would need extremely exact description...
Yes, certainly it may be impossible to ever do it all..
But I think it's worthwhile to do the thought experiment of asking what
is the best we could feasibly do (putting aside for the moment the
question of who's actually going to find time to write the code), because
what you get from the conversion process is one of the most critical
issues for a project like FreeBSD deciding to move to SVN.
-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
Re: [PATCH] "simple" custom keywords implementation
Posted by kf...@collab.net.
Archie Cobbs <ar...@dellroad.org> writes:
> 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.
What makes you think current tools (such as cvs2svn) lose any history?
Having it be clear exactly how they work is another matter.
Conversion from CVS to SVN is inherently complex; to make it clear how
a conversion works means describing something very complex. Certainly
cvs2svn could be better documented (I don't know about the other
converters), but it sounds like you're wishing for simplicity where
none can ever be.
> (+) 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.
cvs2svn.py has this (modulo bugs). Of course, to make the prediction,
you have to essentially do the same logic cvs2svn 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.
We need to add that.
> (+) Configurable ability to map vendor branches into a local or
> global subdirectory, etc. (How would this work exactly?)
Your parenthetical question is the heart of the matter.
> (+) Configurable ability to map labeled CVS branches and tags into
> user-defined subtrees, etc. (How would this work exactly?)
Same.
> (+) 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).
That would be great. Not sure how to do recognize repository hackage
like that w/ acceptable performance.
Your converter wish list is great, I just think it's asking for the
moon :-). The problem is very, very, very, very, very hard. Just to
get it to work "correctly" at all is hard. Any enhancement beyond
that would need extremely exact description...
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] "simple" custom keywords implementation
Posted by Branko Čibej <br...@xbc.nu>.
Ben Reser wrote:
>Compression has been discussed, but I don't think it'll happen. We're
>not aware of a compression library that meets our licensing or platform
>requirements.
>
Heh heh heh. We already have a compression library that completely meets
our licensing and platform requirements. I should know, I implemented
it. It's called vdelta. It's not quite as good as zlib (which also
happens to have an acceptable license), but it's reasonably fast.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] "simple" custom keywords implementation
Posted by Ben Reser <be...@reser.org>.
On Sun, Jul 04, 2004 at 10:19:05PM +0200, Tobias_Ringström wrote:
> Ben Reser wrote:
>
> >Compression has been discussed, but I don't think it'll happen. We're
> >not aware of a compression library that meets our licensing or platform
> >requirements. Plus compression could be slow. While compression is
> >
> >
> What's wrong with zlib?
You know now that I think about it I don't know. I just remember that
being an issue the last time this discussion came up...
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] "simple" custom keywords implementation
Posted by Tobias Ringström <to...@ringstrom.mine.nu>.
Ben Reser wrote:
>Compression has been discussed, but I don't think it'll happen. We're
>not aware of a compression library that meets our licensing or platform
>requirements. Plus compression could be slow. While compression is
>
>
What's wrong with zlib?
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] "simple" custom keywords implementation
Posted by Ben Reser <be...@reser.org>.
On Sun, Jun 13, 2004 at 02:53:47PM -0500, Archie Cobbs wrote:
> 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.
SVN::Mirror is just such a tool. In fact svk, a different front end
that doesn't use our working copies probably meets the usage model you
are looking for. On top of all that it gives you merge history. And
works just fine alongside with people using the standard client. You
may want to take a look at it:
http://svk.elixus.org/
> That sounds like a reasonably intuitive usage model. I think this combined
> with compression should satisfy most pepole who care about disk space.
Compression has been discussed, but I don't think it'll happen. We're
not aware of a compression library that meets our licensing or platform
requirements. Plus compression could be slow. While compression is
usually cheap to read, it's usually expensive to write. So checkouts
would likely be slow. I think the far more likely solution will be
allowing the text-base to be ommitted and maybe built on demand. But as
has been discussed here before, this will likely require a complete
rewrite of the wc system, which won't happen until 2.0.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] "simple" custom keywords implementation
Posted by John Peacock <jp...@rowman.com>.
Archie Cobbs wrote:
> 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.
If you'd read that section in HACKING, you would have been referred to this page:
http://apr.apache.org/versioning.html
which makes it very clear that minor versions must be both source and binary
compatible with older minor versions. It took more than a little work on my
part to ensure what I was doing would manage that. In fact, if you look at the
issue 890 history, you'll see that I produced two patches:
1) which only replaces the core code in svn_subst (and associated include files)
so that all other internal Subversion code must operate correctly using the
compatibility functions; and
2) a patch which replaces all other internal Subversion code with the more
efficient direct calls to the new functions.
I'll take a look at your code to see if there is anything that I can incorporate
into what I have already done. I like the idea of equivalence between short and
long forms in svn:keywords; I think my code does that already but I want to make
sure.
As for the custom keyword portion, I think I'd rather work on a more general
solution than just creating aliases for the existing keywords. plasma's
original patch was intended to be used to permit generic keyword definitions
using a printf-style format string. The problem is still that there is no way
short of compile-time options (like you used) to create those custom keywords.
I'd much rather work on a way for the client to query the server for repository
specific keyword definitions, rather than hardcoding something.
At the very least, if there was a consensus that a hardcoded route was
acceptable for a short-term case, I would put that in an include file which
could incorporate the site-specific keywords. Actually, typing this out makes
me want to see how hard that would be to do...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] "simple" custom keywords implementation
Posted by Archie Cobbs <ar...@dellroad.org>.
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
Re: [PATCH] "simple" custom keywords implementation
Posted by Greg Hudson <gh...@MIT.EDU>.
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