question clarification needed (tagging with embedded externals)
steve
Second, a bit of clarification, ok so i have a project with embedded externals, if i do a tag to "back-up" a specific release - does the tagged version convert the external into a quasi-revisioned copy?
for instance consider:
./proj_x/a
./proj_x/b
./proj_x/c
./proj_x/d
where "./proj_x/d" contains the original files that are selected as externals, and are used in submodules a-c:
as in:
./proj_x/a/d (as external link to ../d)
./proj_x/b/d (as external link to ../d)
./proj_x/c/d (as external link to ../d)
so when i i tag "./proj_x"
to ../tags/proj_x_ReleaseC_1
and someone else uses that tagged info (via checkout) to build the project (proj_x_ReleaseC_1) - will they get the externals relative to the tagged release (proj_x_ReleaseC_1), or will they get the most recent versions of the externals (proj_x/d)?
Im hoping they get the externals relative to the tag (proj_x_ReleaseC_1) but wanted to clarify before tagging the 'proj_x' release in the repo.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2371888
To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].
Lübbe Onken
> First want to point out that the link to the pdf docs aren't working at: http://tortoisesvn.net/support > help > docs
which one? I tried English and it works for me.
--
Cheers
- Lübbe
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net PGP Key ID 0x23F511AB
steve
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2372124
KJ
>
> so when i i tag "./proj_x"
> to ../tags/proj_x_ReleaseC_1
>
> and someone else uses that tagged info (via checkout) to build the project (proj_x_ReleaseC_1) - will they get > the externals relative to the tagged release (proj_x_ReleaseC_1), or will they get the most recent versions of the externals (proj_x/d)?
>
They will get the most recent not the version that existed at the time
of tag creation. That behaviour (actually the lack of any option to
allow for such a copy to be made) is a gripe of mine. It's a
limitation/feature (depending on who you ask) of Subversion, not
Tortoise.
> Im hoping they get the externals relative to the tag (proj_x_ReleaseC_1) but wanted to clarify before tagging the 'proj_x' release in the repo.
>
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.
KJ
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2372317
steve
> On Jul 16, 5:38 pm, steve <strange_st...@yahoo.com> wrote:
> >
> > so when i i tag "./proj_x"
> > to ../tags/proj_x_ReleaseC_1
> >
> > and someone else uses that tagged info (via checkout) to build the project (proj_x_ReleaseC_1) - will they get the externals relative to the tagged release (proj_x_ReleaseC_1), or will they get the most recent versions of the externals (proj_x/d)?
> >
>
> They will get the most recent not the version that existed at the time
> of tag creation. That behaviour (actually the lack of any option to
> allow for such a copy to be made) is a gripe of mine. It's a
> limitation/feature (depending on who you ask) of Subversion, not
> Tortoise.
>
Oh wow - :( has anyone brought up this point to both development teams? Wasn't expecting this answer at all, went through alot of stuff to get the externals working in my projects, all of which use nearly the same files, very disappointing... would hate to have to export the design tree and then check-in everything in again (in different area) - to do a true "tag" operation
>
> 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.
>
Ok um so this script would allow me to "pin down" a external for a 'tag' operation is that right? um - does anyone know if there is a way to run this as a hook through the windows gui? Is there a was to replace the whole existing 'svn copy' command on the server with this new version?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2372711
steve
--- On Mon, 7/20/09, Ryan Schmidt
Date: Monday, July 20, 2009, 2:26 PM
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://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2374465
Robin Guest
was hoping to avoid cross posting but - here is what the subversion team had to say about this issue, im sorry but its a bit lengthly. has anyone else here had to deal with this issue (taggng & externals)?
Robin Guest
Sure. I always manually add revisions to my externals before I tag them. Takes all of 10 seconds extra. I change the svn:externals property in my up-to-date wc, tag from the wc, leaving the wc pointing at trunk, then revert it afterwards.
KJ
> 2009/7/22 Robin Guest <robin.gu...@gmail.com>
>
> > Sure. I always manually add revisions to my externals before I tag them.
> > Takes all of 10 seconds extra. I change the svn:externals property in my
> > up-to-date wc, tag from the wc, leaving the wc pointing at trunk, then
> > revert it afterwards.
If you typically only have one or two externals then the '10 seconds
extra' and manual verification that you did it correctly may not be a
big deal. On the other hand, if you have a lot of externals that pull
together IP that is intended for reuse and that is still being
developed (possibly by multiple developers) you'll soon grow weary of
having to lock down each and every external (and wonder if you missed
one) prior to doing a build just so you can reliably reproduce the
source from the archive. The end result is either:
- No reliable place to go to get the latest/greatest IP for a
particular module (because each user of the module basically ended up
copying/replicating a snapshot and improved only their 'local'
version...maybe it got copied back to the trunk...maybe not).
- Or...you spend a lot of time and effort updating all of the external
links to lock them down...right when you're trying to finish up and
get a release out the door (bad timing for that task)
- Or...no reliable mechanism to exactly reproduce the source files
because the external link will always pull the head, not the revision
that was in place when the 'tag' was created.
>
> Another thing I regularly do is to make my externals point to tags of the
> external thing, rather than the trunk of the external thing. Since by
> convention tags are never changed, I'm then unlikely to get a wrong version.
> This doesn't guard against the target of the external being moved in the
> repo, though. Only an "@nnnnn"-style revision (peg revision) can cope with
> that.
>
And for relatively 'static' things that are externals, that's maybe
not so much of a hardship to do that extra work. If you consider
instead a project that is a collection of sub-projects where each of
the sub-projects is intended for reuse in other projects as well...and
everything (projects and subs) are all still under development you
might want to re-think that approach.
Again, I don't see this as a Tortoise limitation but a Subversion
one...but the Subversion folks don't seem to buy into this being a
limitation at all...in spite of the several requests and the existence
of svncopy.pl which explains the problem in detail as well.
KJ
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2374807
steve
I posted a new-feature suggestion for externals so its easier to do a proper tag operation to the following thread (sorry about the cross post, but both threads were relevant), to keep things clean will only attach link below. Im hoping to hear from TSVN developers to see if the changes are possible, as KJ was hinting at there is definitely a need to resolve this issue.
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2374494
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2374867
yettyn
topic but feel it fits in pretty well here.
On Jul 22, 5:13 pm, Robin Guest <robin.gu...@gmail.com> wrote:
> 2009/7/22 steve <strange_st...@yahoo.com>
>
> Sure. I always manually add revisions to my externals before I tag them.
> Takes all of 10 seconds extra. I change the svn:externals property in my
> up-to-date wc, tag from the wc, leaving the wc pointing at trunk, then
> revert it afterwards.
>
I just wonder, to get some clarity, when you say "tag from the wc" if
you mean that in the tsvn "Copy (Branch / Tag)" dialog and "Create
copy in the the repository from:" select "Working copy"?
It might be very clear to some but I would like to have it w/o doubt,
also if there are any special benefits from doing it that way then
using one of the other options? I'm not sure but possibly you have to
commit the prop change first before you can tag and then commit again
as changing back, is that it simply?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2375703
Robin Guest
> Takes all of 10 seconds extra. I change the svn:externals property in my
> up-to-date wc, tag from the wc, leaving the wc pointing at trunk, then
> revert it afterwards.
I just wonder, to get some clarity, when you say "tag from the wc" ifyou mean that in the tsvn "Copy (Branch / Tag)" dialog and "Create
copy in the the repository from:" select "Working copy"?
It might be very clear to some but I would like to have it w/o doubt
also if there are any special benefits from doing it that way then
using one of the other options? I'm not sure but possibly you have to
commit the prop change first before you can tag and then commit again
as changing back, is that it simply?
Bob Archer
> Yes. Typically, I change at least two things in my final working copy before I tag it.
>As well as pegging the revisions that I already mentioned, I also add the msi installer I just built. This installer is not a versioned file, so >never appears anywhere in trunk, but I do want to keep an archive copy of the exact installer that was shipped out, so it goes in the >tag inside a Release directory.
Interesting. Are you saying that when you tag from working copy files that are not in svn are added to the tag? I didn't know that would happen.
BOb
Robin Guest
Interesting. Are you saying that when you tag from working copy files that are not in svn are added to the tag? I didn't know that would happen.
Bob Archer
Ok,
So after you put the /Release folder and the .msi file into your WC you do an TSVN -> ADD?
Then you do the tag from WC then you revert the WC?
Is that the steps you are taking? I'm just trying to understand. I was not aware you could do that. It's pretty slick way to do it, I must admit.
BOb
Robin Guest
So after you put the /Release folder and the .msi file into your WC you do an TSVN -> ADD? Then you do the tag from WC then you revert the WC?