On Tuesday, November 22, 2011 12:23 AM, "Johan Corveleyn" <jcorvel_at_gmail.com> wrote:
> Hi all,
>
> I'm wondering if it would be feasible to (make it possible to)
> alter/add copyfrom information in an SVN repository. And if so, would
> this be a desirable feature?
It's not feasible for FSFS without a format bump and a new layer of
code. I believe trivial for BDB though.
I'm not really sure it's desirable. If you are to poke a hole in the
immutability guarantee it should be a very small one.
>
> It would certainly be useful (although I can't fully estimate the
> ramifications) for the following use case:
>
> - User commits a move, but for some reason it's lacking copyfrom
> information (possible reasons are 'svn mv A B; svn mv B A' with svn <
> 1.7 [1]; or user performed a non-svn move; ...)
Not convinced that we should add a new backend feature because users
don't know the tool they work with.
> Currently, the only way I know to repair this, is:
>
> svn rm thefile
> svn copy $URL/thefile_at_REV-BEFORE-BREAKAGE .
> # replay all the text modifications after the breakage,
> # and commit them one by one
> # or alternatively: replace the text by the latest version,
> # and commit all at once (less nice history (collapsed))
>
> This can be a lot of work (especially if a lot of commits have gone by
> since the breakage, or if multiple files (dirs) are involved which
> each evolved differently afterwards). Not to mention that it can
> become quite ugly if commits are replayed one by one (builds failing
> in the meantime, ...).
>
It's automateable.
You also don't mention the "other" way of fixing this --- noticing the
lack of copyfrom information in the commit mail.
(or just putting up with it. I could argue that your way is dangerous
since it introduces duplications into history; anyone reading it would
have to manually verify that the "repeated" commits are in fact
identical to the original ones past the break-of-copyfrom)
> In this case, it would be very useful if one could simply add the
> missing copyfrom information to the repository. I can think of several
> possible ways:
> - On a live repository (like editing revprops (possibly protected by a hook))
> - With an svnadmin command
> - By dumpfile manipulation, if nothing else
>
"By an svnadmin command" is pretty meaningless, it describes the UI
rather than the implementation.
The options you have are:
- live filesystem disk tree
- non-live filesystem disk tree
- editor drive
- dumpstream
- dumpfile
>
> Thoughts, opinions, ...?
>
I'm not convinced that we need to complicate the backend because users
don't know the tool they work with.
I'd suggest that you switch your repositories to BDB and manually edit
the noderev skels. Alternatively, patching svnsync or svndumptool should
be simple; perhaps something like the below, plus some machinery to read
a hash mapping [path, revision] pairs to their new copyfrom tuples.
[[[
Index: sync.c
===================================================================
--- sync.c (revision 1202151)
+++ sync.c (working copy)
@@ -281,10 +281,16 @@ add_file(const char *path,
if (copyfrom_path)
copyfrom_path = apr_psprintf(pool, "%s%s", eb->to_url,
svn_path_uri_encode(copyfrom_path, pool));
+ if (eb->base_revision == FOO && !strcmp(path, BAR))
+ {
+ copyfrom_path = "/baz";
+ copyfrom_rev = "42";
+ }
+
SVN_ERR(eb->wrapped_editor->add_file(path, pb->wrapped_node_baton,
copyfrom_path, copyfrom_rev,
pool, &fb->wrapped_node_baton));
fb->edit_baton = eb;
]]]
> --
> Johan
>
> [1] http://subversion.tigris.org/issues/show_bug.cgi?id=3429 - "svn mv
> A B; svn mv B A" generates replace without history (fixed in 1.7)
>
WDYT?
Received on 2011-11-22 08:27:19 CET