Tagging svn:externals
C M
We have defined a structure such that child projects have link from a parent project.
Parent project -> child project_1
-> child project_2
-> child project_3
However, when you go to tag a release for a child, there's nothing in the /tags/Rel_X as I would normally expect.
What's going on here?
Amad
Geoff Hoffman
Connect with us on twitter, google+, facebook, or linkedin.
Catch our next training in St Louis Feb 25 - Mar 1, Vancouver Mar 4 - 8, New York City Mar 11 - 15, Atlanta Apr 10 - 12 or See All.
This email, including any attachments, is for the sole use of the intended recipient and may contain confidential information. If you are not the intended recipient, please immediately notify us by reply email or by telephone, delete this email and destroy any copies. Thank you.
Bob Archer
Some clients like TortoiseSVN have a feature that will pin the external to the revision you are copping when doing the tag. Otherwise, you have to do it manually before or after you create your tag.
C M
I am just not clear on why a simple copy (tag) doesn't work against externals.
Les Mikesell
> Some clients like TortoiseSVN have a feature that will pin the external to
> the revision you are copping when doing the tag. Otherwise, you have to do
> it manually before or after you create your tag.
intermediate branch to make the change. That is, if you make it on
the trunk before you copy to the tag you break the likely continuing
work on the trunk that expects the externals to also follow trunk
components. And if you change it in the tag you are breaking the
convention that you don't change tags. And if you copy the working
copy to a tag you might get other changes in the tag that weren't
committed anywhere else. Is there a 'best practice' consensus for
this step?
--
Les Mikesell
lesmi...@gmail.com
Les Mikesell
> The external definitions do specify a revision. That part is working fine.
>
> I am just not clear on why a simple copy (tag) doesn't work against
> externals.
externals as the source.
--
Les Mikesell
lesmi...@gmail.com
C M
Mind you I am using the Tortoise SVN 1.7 client to do the copy.
Les Mikesell
> I am not seeing anything in: /tags/Rel_1.0.
>
> Mind you I am using the Tortoise SVN 1.7 client to do the copy.
externals, if that is what you are expecting. But if the thing you
tag has external references, you should get the same structure
re-created when you check it out. That is, it copies the reference
only. The usual issue with this is that if the externals point to
trunk versions without peg revisions, the subsequent checkout may pull
in components that are newer than what you tagged. But it sounds
like you have some other issue or misunderstanding.
--
Les Mikesell
lesmi...@gmail.com
BRM
> To: Bob Archer <Bob.A...@amsi.com>
> Cc: C M <cmana...@gmail.com>; "us...@subversion.apache.org" <us...@subversion.apache.org>
> Sent: Wednesday, February 20, 2013 1:03 PM
> Subject: Re: Tagging svn:externals
While I do agree, I think the simple solution is to generally just use tagged externals to start with, and then switch them to trunk or a branch when you need to work on them from that project.
Not only does it solve the above, but it also enforces a discipline in how projects are updated to use newer versions of the tags; it also requires developers to be aware of which externals affect which projects - which, IMHO, is a good thing.
$0.02
Ben
Les Mikesell
>
>> On Wed, Feb 20, 2013 at 11:52 AM, Bob Archer <Bob.A...@amsi.com> wrote:
>>> Some clients like TortoiseSVN have a feature that will pin the external to
>>> the revision you are copping when doing the tag. Otherwise, you have to do
>>> it manually before or after you create your tag.
>>
>> Neither choice 'feels' quite right to me unless you have an
>> intermediate branch to make the change. That is, if you make it on
>> the trunk before you copy to the tag you break the likely continuing
>> work on the trunk that expects the externals to also follow trunk
>> components. And if you change it in the tag you are breaking the
>> convention that you don't change tags. And if you copy the working
>> copy to a tag you might get other changes in the tag that weren't
>> committed anywhere else. Is there a 'best practice' consensus for
>> this step?
>>
>
> While I do agree, I think the simple solution is to generally just use tagged externals to start with, and then switch them to trunk or a branch when you need to work on them from that project.
and the project using it. But that is the problem case - and common.
> Not only does it solve the above, but it also enforces a discipline in how projects are updated to use newer versions of the tags; it also requires developers to be aware of which externals affect which projects - which, IMHO, is a good thing.
APIs at release quality before any upper level project touched them.
But on the other hand, APIs tend to miss the mark if they aren't
adjusted for the needs of real-world use. So there's a problem either
way....
--
Les Mikesell
lesmi...@gmail.com
Philip Martin
> Neither choice 'feels' quite right to me unless you have an
> intermediate branch to make the change. That is, if you make it on
> the trunk before you copy to the tag you break the likely continuing
> work on the trunk that expects the externals to also follow trunk
> components. And if you change it in the tag you are breaking the
> convention that you don't change tags. And if you copy the working
> copy to a tag you might get other changes in the tag that weren't
> committed anywhere else. Is there a 'best practice' consensus for
> this step?
change happen in the same commit. We do something like that when
tagging Subversion, we edit a header when we make a tag:
$ svn log -vq --stop-on-copy http://svn.apache.org/repos/asf/subversion/tags/1.7.8
------------------------------------------------------------------------
r1419826 | breser | 2012-12-10 22:01:28 +0000 (Mon, 10 Dec 2012)
Changed paths:
A /subversion/tags/1.7.8 (from /subversion/branches/1.7.x:1419691)
M /subversion/tags/1.7.8/subversion/include/svn_version.h
------------------------------------------------------------------------
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Ryan Schmidt
On Feb 21, 2013, at 11:18, Philip Martin wrote:
> Les Mikesell writes:
>
>> Neither choice 'feels' quite right to me unless you have an
>> intermediate branch to make the change. That is, if you make it on
>> the trunk before you copy to the tag you break the likely continuing
>> work on the trunk that expects the externals to also follow trunk
>> components. And if you change it in the tag you are breaking the
>> convention that you don't change tags. And if you copy the working
>> copy to a tag you might get other changes in the tag that weren't
>> committed anywhere else. Is there a 'best practice' consensus for
>> this step?
>
> You could write a script using svnmucc so that the copy and the property
> change happen in the same commit. We do something like that when
> tagging Subversion, we edit a header when we make a tag:
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svncopy/svncopy.README
BRM
> To: BRM <bm_wi...@yahoo.com>
> Cc: "us...@subversion.apache.org" <us...@subversion.apache.org>
> Sent: Thursday, February 21, 2013 11:09 AM
> Subject: Re: Tagging svn:externals
>
All true. But that's what your release process is for. Part of my release process for the projects that use svn:externals is to first tag and release any externals that are not released already.
And if I don't need to modify an external during development, then it never moves from the release the project used.
Now, in a sense you're looking to do that automatically as you make a release of the project you're working on.
But it really all comes down to the release process, the tools you use for release, and their capabilities.
$0.02
Ben
Les Mikesell
>
>>> Not only does it solve the above, but it also enforces a discipline in how
>> projects are updated to use newer versions of the tags; it also requires
>> developers to be aware of which externals affect which projects - which, IMHO,
>> is a good thing.
>>
>> Sure, it would be great if every component had well-tested, frozen
>> APIs at release quality before any upper level project touched them.
>> But on the other hand, APIs tend to miss the mark if they aren't
>> adjusted for the needs of real-world use. So there's a problem either
>> way....
>
> All true. But that's what your release process is for. Part of my release process for the projects that use svn:externals is to first tag and release any externals that are not released already.
these are dead ends if QA rejects them - that is, with rare exceptions
anything that needs to be fixed would be fixed on the trunk and a new
QA tag made. My thinking is that there really should be an
intermediate QA branch where the externals are pinned but it seems
like a big waste when there will never be any other change on that
branch. Plus, we are increasingly automating this with a jenkins
plugin that allows tagging after a build.
> And if I don't need to modify an external during development, then it never moves from the release the project used.
trunk work on the upper level projects, but it is still a common
scenario to need to make changes in both simultaneously.
> Now, in a sense you're looking to do that automatically as you make a release of the project you're working on.
> But it really all comes down to the release process, the tools you use for release, and their capabilities.
revisions in the same repository. How would anything automatic find
the right component tag or deal with concurrent changes in a separate
repo?
--
Les Mikesell
lesmi...@gmail.com
BRM
> To: BRM <bm_wi...@yahoo.com>
> Cc: "us...@subversion.apache.org" <us...@subversion.apache.org>
> Sent: Friday, February 22, 2013 10:57 AM
> Subject: Re: Tagging svn:externals
It's fully a matter of how you structure release process for anyone.
If you keep trunk prestine, then I don't think that would be an issue - your process just has to say that trunk
can only have released svn:externals and always be ready for QA.
And QA would have to have a similar process specified for any updates they do.
Ultimately nothing I/we say can do anything but help you define the process
and how it needs to work for you and your team(s).
>> And if I don't need to modify an external during development, then it
> never moves from the release the project used.
>
> Sure, many/most stay tied to tagged component releases even during
> trunk work on the upper level projects, but it is still a common
> scenario to need to make changes in both simultaneously.
I don't think that would be an issue. Again, it's how you define the process for your developers/QA Testers/QA Fixers.
>> Now, in a sense you're looking to do that automatically as you make a
> release of the project you're working on.
>> But it really all comes down to the release process, the tools you use for
> release, and their capabilities.
> I don't think you can do it automatically unless you pin to peg
> revisions in the same repository. How would anything automatic find
> the right component tag or deal with concurrent changes in a separate
> repo?
By automation I mean having scripts setup that can update the pegs revisions or tags automatically.
It can be relatively easy to do (depending on the scripting language) but will be very specific to your repository use.
The script would just need to be able to parse "svn pget svn:externals" and "svn info" on the various externals.
I'm not saying its the full solution - or even the right one; just that that is how you are seeming to want to go.
Personally I think the right solution is defining your processes for everyone.
Keep it easy to do, but make sure everyone understands what they are suppose to do.
Ben
Les Mikesell
>>>
>> Agreed, but the scenario is making a QA tag from trunk work. Most of
>> these are dead ends if QA rejects them - that is, with rare exceptions
>> anything that needs to be fixed would be fixed on the trunk and a new
>> QA tag made. My thinking is that there really should be an
>> intermediate QA branch where the externals are pinned but it seems
>> like a big waste when there will never be any other change on that
>> branch. Plus, we are increasingly automating this with a jenkins
>> plugin that allows tagging after a build.
>
> It's fully a matter of how you structure release process for anyone.
> If you keep trunk prestine, then I don't think that would be an issue - your process just has to say that trunk
> can only have released svn:externals and always be ready for QA.
> And QA would have to have a similar process specified for any updates they do.
> Ultimately nothing I/we say can do anything but help you define the process
> and how it needs to work for you and your team(s).
practices" document on how best deal with the inherent conflict
between the concepts of concurrent development on trunk, and the
conventions of (a) externals always being pegged in tags and (b) no
changes _after_ tagging. The only clean approach looks to me like
making a branch whose only purpose is to be a place to make the change
to the external references - but that also seem like a lot of extra
effort and clutter in the repository for that operation. But, if
that is what it takes, it would be easier to convince developers to do
it that way if there were some official document describing it.
>> Sure, many/most stay tied to tagged component releases even during
>> trunk work on the upper level projects, but it is still a common
>> scenario to need to make changes in both simultaneously.
>
> I don't think that would be an issue. Again, it's how you define the process for your developers/QA Testers/QA Fixers.
a different workflow process to accomplish the same thing...
>>> Now, in a sense you're looking to do that automatically as you make a
>> release of the project you're working on.
>>> But it really all comes down to the release process, the tools you use for
>> release, and their capabilities.
>> I don't think you can do it automatically unless you pin to peg
>> revisions in the same repository. How would anything automatic find
>> the right component tag or deal with concurrent changes in a separate
>> repo?
>
> By automation I mean having scripts setup that can update the pegs revisions or tags automatically.
> It can be relatively easy to do (depending on the scripting language) but will be very specific to your repository use.
which is currently pointing at the trunk in a repository that permits
concurrent operations?
> The script would just need to be able to parse "svn pget svn:externals" and "svn info" on the various externals.
> I'm not saying its the full solution - or even the right one; just that that is how you are seeming to want to go.
>
> Personally I think the right solution is defining your processes for everyone.
> Keep it easy to do, but make sure everyone understands what they are suppose to do.
that doesn't have any obvious benefit. The intermediate branch seems
to have little benefit other than following some abstract conventions
unless there will be later support work on it - and you can always
create the branch later from the tag if that turns out to be
necessary.
--
Les Mikesell
lesmi...@gmail.com
BRM
> To: BRM <bm_wi...@yahoo.com>
> Cc: "us...@subversion.apache.org" <us...@subversion.apache.org>
> Sent: Tuesday, February 26, 2013 11:56 AM
> Subject: Re: Tagging svn:externals
>
> On Tue, Feb 26, 2013 at 8:48 AM, BRM <bm_wi...@yahoo.com> wrote:
>>>>
>>> Agreed, but the scenario is making a QA tag from trunk work. Most of
>>> these are dead ends if QA rejects them - that is, with rare exceptions
>>> anything that needs to be fixed would be fixed on the trunk and a new
>>> QA tag made. My thinking is that there really should be an
>>> intermediate QA branch where the externals are pinned but it seems
>>> like a big waste when there will never be any other change on that
>>> branch. Plus, we are increasingly automating this with a jenkins
>>> plugin that allows tagging after a build.
>>
>> It's fully a matter of how you structure release process for anyone.
>> If you keep trunk prestine, then I don't think that would be an issue -
> your process just has to say that trunk
>> can only have released svn:externals and always be ready for QA.
>> And QA would have to have a similar process specified for any updates they
> do.
>
> We do development on trunk. It just seems like the logical place...
That's one of two recognized methods - trunk is prestine or trunk is "dirty".
For "trunk is dirty" there is no guarantee that any given revision is useable.
For "trunk is prestine" development methodology says any given revision
must be useable. Both are enforced by project preferences and policy.
>> Ultimately nothing I/we say can do anything but help you define the process
>> and how it needs to work for you and your team(s).
>
> On the other hand, it would be helpful if there were a "best
> practices" document on how best deal with the inherent conflict
> between the concepts of concurrent development on trunk, and the
> conventions of (a) externals always being pegged in tags and (b) no
> changes _after_ tagging. The only clean approach looks to me like
> making a branch whose only purpose is to be a place to make the change
> to the external references - but that also seem like a lot of extra
> effort and clutter in the repository for that operation. But, if
> that is what it takes, it would be easier to convince developers to do
> it that way if there were some official document describing it.
From what I can tell - and others can verify this - Subversion tries to allow the
developers to choose the development model that best fits their needs. As
such, such a document would have to be generated for numerous development
models.
That said, I think what you're looking to do makes more sense in a "trunk is prestine"
model than a "trunk is dirty" model. My own repositories use the "trunk is prestine"
model.
>>> Sure, many/most stay tied to tagged component releases even during
>>> trunk work on the upper level projects, but it is still a common
>>> scenario to need to make changes in both simultaneously.
>>
>> I don't think that would be an issue. Again, it's how you define
> the process for your developers/QA Testers/QA Fixers.
>
> I'm just saying it would be nicer if every user didn't have to make up
> a different workflow process to accomplish the same thing...
I think it's a matter of finding what works best for your team. Good tools, like Subversion,
make it easy to customize your workflow for what you need to do. Some functions fit
certain workflows better than others; but they are available.
>>>> Now, in a sense you're looking to do that automatically as you
> make a
>>> release of the project you're working on.
>>>> But it really all comes down to the release process, the tools you
> use for
>>> release, and their capabilities.
>>> I don't think you can do it automatically unless you pin to peg
>>> revisions in the same repository. How would anything automatic find
>>> the right component tag or deal with concurrent changes in a separate
>>> repo?
>>
>> By automation I mean having scripts setup that can update the pegs
> revisions or tags automatically.
>> It can be relatively easy to do (depending on the scripting language) but
> will be very specific to your repository use.
>
> How can a script possibly know the correct tag for an external target
> which is currently pointing at the trunk in a repository that permits
> concurrent operations?
In my example, it would simply update, then pull the revision number to generate the peg
revision information in the svn:externals data, essentially:
^/somePath@r1829 -r 1829
The "1829" portion is easily scriptable to find.
>> The script would just need to be able to parse "svn pget
> svn:externals" and "svn info" on the various externals.
>> I'm not saying its the full solution - or even the right one; just that
> that is how you are seeming to want to go.
>>
>> Personally I think the right solution is defining your processes for
> everyone.
>> Keep it easy to do, but make sure everyone understands what they are
> suppose to do.
>
> That is a lot easier if you can make that solution avoid extra work
> that doesn't have any obvious benefit. The intermediate branch seems
> to have little benefit other than following some abstract conventions
> unless there will be later support work on it - and you can always
> create the branch later from the tag if that turns out to be
> necessary.
I would suggest using branches for the features, bug fixes, etc. The normal process
then involves branching for the work, changing the external and updating the main
project accordingly, and reintegrating the branch to trunk when you're done. Everyone
would get the same workflow. Now, that's basically the "trunk is prestine" model.
As you can probably guess, I'm a big fan of "trunk is prestine"; mostly because I'm a
big fan of doing things in a very structured, deterministic way. You seem to be wanting
that determinism. It'd be interesting to see what a big fan of "trunk is dirty" would say
for how to do the same thing; but somehow I suspect you can't do it while maintaining
the determinism.
As always,
$0.02
Ben
Les Mikesell
>
>> How can a script possibly know the correct tag for an external target
>> which is currently pointing at the trunk in a repository that permits
>> concurrent operations?
>
> In my example, it would simply update, then pull the revision number to generate the peg
> revision information in the svn:externals data, essentially:
>
> ^/somePath@r1829 -r 1829
>
> The "1829" portion is easily scriptable to find.
previously tagged component versions. Without forcing that to be
committed to the trunk or encouraging copying to tags from a workspace
that doesn't match any trunk commit.
>
> As you can probably guess, I'm a big fan of "trunk is prestine"; mostly because I'm a
> big fan of doing things in a very structured, deterministic way.
and in making it simple for everyone involved to pick up each others'
changes sooner rather than later. And in getting determinism through
consistent tagging, and only using release tags where determinism
matters.
> You seem to be wanting
> that determinism. It'd be interesting to see what a big fan of "trunk is dirty" would say
> for how to do the same thing; but somehow I suspect you can't do it while maintaining
> the determinism.
where/how that change between an unpinned external and one pointing to
a separately released tagged version should happen. I don't think
whether the ongoing work is a branch or trunk matters. As long there
is continuing (possibly concurrent) development in the location before
you make the tag, you have to decide whether to (a) make another
branch just to hold this change, (b) commit the change back to the
development location, then undo it after the tag copy, (c) copy to the
tag from a modified working copy, or (d) change it in the tag,
violating the 'tags never change' convention? I personally don't
like the idea of tagging from a modified working copy because of the
possibility that other changes with no history can accidentally be
brought along.
--
Les Mikesell
lesmi...@gmail.com
BRM
> To: BRM <bm_wi...@yahoo.com>
> Cc: "us...@subversion.apache.org" <us...@subversion.apache.org>
> Sent: Tuesday, February 26, 2013 6:12 PM
> Subject: Re: Tagging svn:externals
>
> On Tue, Feb 26, 2013 at 4:29 PM, BRM <bm_wi...@yahoo.com> wrote:
>>
>>> How can a script possibly know the correct tag for an external target
>>> which is currently pointing at the trunk in a repository that permits
>>> concurrent operations?
>>
>> In my example, it would simply update, then pull the revision number to
> generate the peg
>> revision information in the svn:externals data, essentially:
>>
>> ^/somePath@r1829 -r 1829
>>
>> The "1829" portion is easily scriptable to find.
>
> But that's not what I want. I want the externals in tags to point to
> previously tagged component versions. Without forcing that to be
> committed to the trunk or encouraging copying to tags from a workspace
> that doesn't match any trunk commit.
From that description, it'll have to be a manual process that you run from within your working copy.
Just update the svn:externals appropriately and then do an "svn update".
You can test whatever you like without committing.
>> As you can probably guess, I'm a big fan of "trunk is
> prestine"; mostly because I'm a
>> big fan of doing things in a very structured, deterministic way.
>
> I'm a fan of not cluttering the repository with unnecessary branches,
> and in making it simple for everyone involved to pick up each others'
> changes sooner rather than later. And in getting determinism through
> consistent tagging, and only using release tags where determinism
> matters.
So if you don't need a branch, delete it.
Personally I do an "svn del" on any branch that I no longer need - whether abandoned or reintegrated.
This keeps the branch list short, and (more importantly) relevant.
The nice thing with Subversion is that you can still get to all those old branches.
>> You seem to be wanting
>> that determinism. It'd be interesting to see what a big fan of
> "trunk is dirty" would say
>> for how to do the same thing; but somehow I suspect you can't do it
> while maintaining
>> the determinism.
>
> The question is just about what would be considered "best practice" in
> where/how that change between an unpinned external and one pointing to
> a separately released tagged version should happen. I don't think
> whether the ongoing work is a branch or trunk matters. As long there
> is continuing (possibly concurrent) development in the location before
> you make the tag, you have to decide whether to (a) make another
> branch just to hold this change, (b) commit the change back to the
> development location, then undo it after the tag copy, (c) copy to the
> tag from a modified working copy, or (d) change it in the tag,
> violating the 'tags never change' convention? I personally don't
> like the idea of tagging from a modified working copy because of the
> possibility that other changes with no history can accidentally be
> brought along.
Let me propose this:
For QA, let them do a simple modified working copy to get the svn:externals where you want them; but then they are not allowed to commit or make other changes.
You'll have to decide how you want bug fixes to be interacted with; but that will provide what you've been describing.
For developers, they can do whatever you like.
Again, as I've noted it comes down to what policies you want your team to follow.
Ben
Les Mikesell
>>
>> But that's not what I want. I want the externals in tags to point to
>> previously tagged component versions. Without forcing that to be
>> committed to the trunk or encouraging copying to tags from a workspace
>> that doesn't match any trunk commit.
>
> From that description, it'll have to be a manual process that you run from within your working copy.
> Just update the svn:externals appropriately and then do an "svn update".
> You can test whatever you like without committing.
Things in uncommitted workspaces aren't necessarily repeatable.
>> I'm a fan of not cluttering the repository with unnecessary branches,
>> and in making it simple for everyone involved to pick up each others'
>> changes sooner rather than later. And in getting determinism through
>> consistent tagging, and only using release tags where determinism
>> matters.
>
> So if you don't need a branch, delete it.
> Personally I do an "svn del" on any branch that I no longer need - whether abandoned or reintegrated.
> This keeps the branch list short, and (more importantly) relevant.
> The nice thing with Subversion is that you can still get to all those old branches.
gigs/year. While I realize that extra tags/branches are a very small
part of the problem I don't want to encourage unnecessary clutter
until there is some reasonable way to reorganize and actually remove
things.
>> The question is just about what would be considered "best practice" in
>> where/how that change between an unpinned external and one pointing to
>> a separately released tagged version should happen. I don't think
>> whether the ongoing work is a branch or trunk matters. As long there
>> is continuing (possibly concurrent) development in the location before
>> you make the tag, you have to decide whether to (a) make another
>> branch just to hold this change, (b) commit the change back to the
>> development location, then undo it after the tag copy, (c) copy to the
>> tag from a modified working copy, or (d) change it in the tag,
>> violating the 'tags never change' convention? I personally don't
>> like the idea of tagging from a modified working copy because of the
>> possibility that other changes with no history can accidentally be
>> brought along.
>
> Let me propose this:
>
> For QA, let them do a simple modified working copy to get the svn:externals where you want them; but then they are not allowed to commit or make other changes.
--
Les Mikesell
lesmi...@gmail.com
BRM
> To: BRM <bm_wi...@yahoo.com>
> Cc: "us...@subversion.apache.org" <us...@subversion.apache.org>
> Sent: Wednesday, February 27, 2013 5:30 PM
> Subject: Re: Tagging svn:externals
>
> On Wed, Feb 27, 2013 at 4:14 PM, BRM <bm_wi...@yahoo.com> wrote:
>>>
>>> But that's not what I want. I want the externals in tags to point to
>>> previously tagged component versions. Without forcing that to be
>>> committed to the trunk or encouraging copying to tags from a workspace
>>> that doesn't match any trunk commit.
>> From that description, it'll have to be a manual process that you run
> from within your working copy.
>> Just update the svn:externals appropriately and then do an "svn
> update".
>> You can test whatever you like without committing.
> Everything is built by jenkins and has to come from the repository.
> Things in uncommitted workspaces aren't necessarily repeatable.
,,,
>> Let me propose this:
>>
>> For QA, let them do a simple modified working copy to get the svn:externals
> where you want them; but then they are not allowed to commit or make other
> changes.
>
> Won't work - it has to be committed somewhere or it won't be built.
Perhaps then you need a different tool.
For example, git-svn[1] is might be what you want.
When something is ready for QA it is pushed to a git repository for Jenkins to pick up.
How you change the externals in the process I'm not sure; but it would at least give you
a trackable repository that would mimick a modified working copy.
Otherwise I think you're out of luck if you don't want to (i) commit to trunk, or (ii) create a branch,
but still want to track it in the repository somehow.
Ben
[1] https://www.kernel.org/pub/software/scm/git/docs/git-svn.html
Les Mikesell
>>
>> Won't work - it has to be committed somewhere or it won't be built.
>
> Perhaps then you need a different tool.
> For example, git-svn[1] is might be what you want.
>
> When something is ready for QA it is pushed to a git repository for Jenkins to pick up.
> How you change the externals in the process I'm not sure; but it would at least give you
> a trackable repository that would mimick a modified working copy.
>
> Otherwise I think you're out of luck if you don't want to (i) commit to trunk, or (ii) create a branch,
> but still want to track it in the repository somehow.
change after making the tag. But neither seem like the tool is
designed to do what I'd expect to be a common operation cleanly.
--
Les Mikesell
lesmi...@gmail.com
BRM
> To: BRM <bm_wi...@yahoo.com>
> Cc: "us...@subversion.apache.org" <us...@subversion.apache.org>
> Sent: Wednesday, February 27, 2013 5:49 PM
> Subject: Re: Tagging svn:externals
>
What do you mean?
Branching from a working copy is extremely easy:
$ svn copy . ^/path/to/tag/or/branch
It's a first-class operation in subversion.
Likewise, you can:
$ svn copy . ^/path/to/tag/or/branch
$ svn switch ^/path/to/tag/or/branch
...make modifications here..
$ svn commit
Ben
Les Mikesell
>> No, I think the choices are to tag from the working copy or commit a
>> change after making the tag. But neither seem like the tool is
>> designed to do what I'd expect to be a common operation cleanly.
>
> What do you mean?
>
> Branching from a working copy is extremely easy:
>
> $ svn copy . ^/path/to/tag/or/branch
>
> It's a first-class operation in subversion.
other than the externals is done. But if you aren't careful, you can
easily add items that don't exist anywhere else. And you have to
revert your change before continuing commits to trunk.
> Likewise, you can:
>
> $ svn copy . ^/path/to/tag/or/branch
> $ svn switch ^/path/to/tag/or/branch
> ...make modifications here..
> $ svn commit
the convention of not committing changes to tags. Leaving the
question of which of these would be considered a 'best practice'.
--
Les Mikesell
lesmi...@gmail.com
BRM
> To: BRM <bm_wi...@yahoo.com>
> Cc: "us...@subversion.apache.org" <us...@subversion.apache.org>
> Sent: Thursday, February 28, 2013 5:29 PM
> Subject: Re: Tagging svn:externals
>
You could always use a slightly modified structure for your projects:
trunk
tags
branches
qa
Your "tagging" for QA could be done to the "qa" tree, and then you are no longer
breaking the rule of not modifying tags. You also enforce that actual "tags" (under the
"tags" tree) must from from the "qa" tree; this can be hard-enforced with a pre-commit hook,
or soft enforced in project policy alone.
Ben