On Jul 20, 2009, at 15:25, steve wrote:
> Ok I came across a situation using tortoise and SVN
>
> (http://tortoisesvn.tigris.org/ds/viewMessage.do?
> dsForumId=4061&dsMessageId=2371888)
>
> Basically:
> Ok so i was told to:
>
>> Google for svncopy.pl. It is a Perl script that works with Subversion
>> and is intended to do what I think you are trying to accomplish.
>
> And from my understanding this script would allow me to "pin down"
> a external for a 'tag' operation is that right?
That's the idea. Any external in a thing you copy (to a new tag or to
anywhere else) will get the latest revision burned into the external
definition, so that if you later check out that copy (e.g. that tag)
you will get the revision of the external that was in effect at the
time the copy (tag) was made, as opposed to the revision of the
external at the time you check out, which is what you would get
otherwise.
The other option is to always put a revision specifier in every
external, even on trunk. This is in fact a good idea, IMHO. Because
you don't just care about keeping the external in sync when checking
out a tag. You also care when checking out an older version of trunk.
In one of my projects, I have Program A which has an external
pointing to a specific revision (let's say r123) of Library B. This
means I can commit any changes I want to Library B, including ones
that change its API, without fear of breaking Program A. Later, when
I am in the mood to work on Program A, I can update the Library B
external to a later revision (let's say r146) and make the necessary
changes to Program A so that it can use the new API of Library B.
If you want to have a look, "Program A" is canviz.js, "Library B" is
path.js, and the repository is available by following links from
http://canviz.org/
> um - does anyone know if there is a way to run this as a hook
> through the tortoise windows gui?
Subversion has server-side hooks; it does not have client-side hooks,
and probably won't for a long time or ever for a variety of reasons
which have been explored in many previous mailing list posts.
The folks on the TortoiseSVN mailing list are better-equipped to
answer TortoiseSVN-specific questions. I did a quick Google search
and found that TortoiseSVN does in fact have client-side hooks. They
are documented here:
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-
settings.html#tsvn-dug-settings-hooks
I don't know if they can be used to implement what you want. I do not
use TortoiseSVN.
The developers of TortoiseSVN could perhaps take the ideas of
svncopy.pl and integrate them into TortoiseSVN and give you an option
to use that, but since you were referred to svncopy.pl by the
TortoiseSVN mailing list, I guess this has not thus far occurred.
> Is there a way to replace the whole existing 'svn copy' command on
> the server with this new version?
You would use svncopy.pl instead of using "svn copy" or Tortoise
SVN's copy command.
> Which leds me to wonder after a bit more looking it seems like this
> same issue might have been addressed as part of "Revision 38450" (?)
The log message of revision 38450 in the Subversion repository reads
as follows; I'm not sure if or how this revision relates to this issue.
$ svn log -r 38450 http://svn.collab.net/repos/svn
------------------------------------------------------------------------
r38450 | hwright | 2009-07-20 13:03:36 -0500 (Mon, 20 Jul 2009) | 34
lines
Rev another libsvn_wc private-public API.
(As an aside, having these APIs feels a bit like cheating. I mean,
if we use
them, and they are useful, shouldn't we expose them to the rest of
the world?
Not only do we let others use these APIs, but we also get rid of this
"svn_wc__blah() is not really internal, so we need an *additional*
wrapper
around it to pull out the wc_db param" dance. Oh well, maybe in some
future
life...)
* subversion/include/private/svn_wc_private.h
(svn_wc__versioned_file_modcheck): Rev, adding a wc_ctx, and
updating the
docstring.
* subversion/libsvn_wc/wc.h
(svn_wc__internal_versioned_file_modcheck): New.
* subversion/libsvn_wc/update_editor.c
(merge_file): Update caller.
* subversion/libsvn_wc/questions.c
(compare_and_verify): Get rid of the access baton parameter, and
use a
wc_db instead. Accept only absolute paths.
(svn_wc__internal_versioned_file_modcheck): New.
(svn_wc__versioned_file_modcheck): Update args, call the wrapper.
(svn_wc__text_modified_internal_p): Get a db and absolute paths to
call
compare_and_verify().
* subversion/libsvn_wc/log.c
(log_do_committed): Update caller.
* subversion/libsvn_client/merge.c
(files_same_p): Remove the adm_access param, and require absolute
paths.
(merge_file_deleted): Get some absolute paths and update a caller.
------------------------------------------------------------------------
> and guess i was really looking for more info - wondering if there
> has indeed been a patch or something of this sort to address this
> issue?
As far as I know, Subversion behaves as intended, so there is nothing
to patch, no issue to address, except perhaps in terms of making the
documentation clearer about the behavior that Subversion exhibits.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2372735
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-20 23:27:27 CEST