Re: Tagging svn:externals

[BRM]

> From: Les Mikesell 

> To: BRM 
> Cc: "users@subversion.apache.org" 
> Sent: Thursday, February 21, 2013 11:09 AM
> Subject: Re: Tagging svn:externals
> 
> On Thu, Feb 21, 2013 at 9:42 AM, BRM  wrote:
>> 
>>>  On Wed, Feb 20, 2013 at 11:52 AM, Bob Archer 
>  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.
> 
> That makes sense when you aren't concurrently working on a component
> 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.
> 
> 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.
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

Re: is that possible the same code under two different subversion service provider?

[frame]

Thank you for all the replies and the link.

Actually, I have just finished reading carefully the "externals definition" 
section of the book from top to the bottom. I think "externals definition" 
is the answer to our needs. Sorry, I didn't study "Vendor Branch" section. 

I am planning to put project/aaa/ in company B's repositoty, which the 
partner can access. Then in the main tree, hosted in company A's 
repository, at project directory level, I set the property of externals 
definition to point to www.companyB.com/aaa_repo 

Re: is that possible the same code under two different subversion service provider?

[C. Michael Pilato]

On 02/22/2013 10:07 AM, frame wrote:
> Thank you for all the replies and the link.
> 
> Actually, I have just finished reading carefully the "externals definition"
> section of the book from top to the bottom. I think "externals definition"
> is the answer to our needs. Sorry, I didn't study "Vendor Branch" section.
> 
> I am planning to put project/aaa/ in company B's repositoty, which the
> partner can access. Then in the main tree, hosted in company A's repository,
> at project directory level, I set the property of externals definition to
> point to www.companyB.com/aaa_repo

Cool.  The externals definition feature didn't even cross my mind, but yeah,
I think that would suit you well.

-- 
C. Michael Pilato 
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development



signature.asc
Description: OpenPGP digital signature

Re: Tagging svn:externals

[Les Mikesell]

On Fri, Feb 22, 2013 at 9:02 AM, BRM  wrote:

>
>>>  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.

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.

> 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.

> 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?

-- 
  Les Mikesell
  lesmikes...@gmail.com

Re: is that possible the same code under two different subversion service provider?

[Thorsten Schöning]

Guten Tag frame,
am Freitag, 22. Februar 2013 um 16:07 schrieben Sie:

> I am planning to put project/aaa/ in company B's repositoty, which
> the partner can access. Then in the main tree, hosted in company A's
> repository, at project directory level, I set the property of
> externals definition to point to www.companyB.com/aaa_repo 

With this approach you loose history of new developments of
project/aaa and depend on company B with everything you are doing with
project/aaa and which is not already checked out somewhere, because
you don't merge any code back into your own repo. It's something which
I would consider really carefully.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Subversion 1.7 on RHEL 4.x

[Nico Kadel-Garcia]

Benson, hi.  Did you ever get Subversion 1.7 working well on RHEL  or
CentOS 4.x? I took a glance back at my old RPM building tools for
Subversion 1.6.20 and 1.7.8, and getting 1.7.8 built on RHEL 4 was a
pain in the keister. In particular, I wound up having to build and
install libserf to avoid dependency issues with out of date neon.

I don't have a professional need for RHEL 4 anymore, but if you need
Subverision 1.7 there and want to keep things tested, I'd be happy to
help you get RPM building working well for that environment. If you
can test it, we can get it into Repoforge "extras" and make your life
easier in the future.

Re: is that possible the same code under two different subversion service provider?

[frame]

On Friday, February 22, 2013 11:13:49 AM UTC-5, Thorsten Schöning wrote:
>
> Guten Tag frame, 
>
>
> With this approach you loose history of new developments of 
> project/aaa and depend on company B with everything you are doing with 
> project/aaa and which is not already checked out somewhere, because 
> you don't merge any code back into your own repo. It's something which 
> I would consider really carefully. 
>
> Sorry, I don't quite understand what you said. Why will I loose the 
history of new developments of project/aaa? If I modify something in 
project/aaa and I check in, which will be in company B's repo. My partner 
abroad who only cares about project/aaa runs "svn update", he will pull out 
my change to his local area, together with the history. If he makes changes 
and check in his change(to company B's repo), I run "svn update" at the 
level of project/, I will get his new code(in aaa/) together with new code 
in bbb/ which is from company A's repo. I should be able to see his commit 
hisotry, right?
I thought this is one of the ideal scenarios exploiting the power of svn 
externals definition. 

Re: is that possible the same code under two different subversion service provider?

[Thorsten Schöning]

Guten Tag frame,
am Freitag, 22. Februar 2013 um 17:33 schrieben Sie:

> I should be able to see his commit hisotry, right?
> I thought this is one of the ideal scenarios exploiting the power of svn 
> externals definition.

Of course this will work, I just wanted to mention that using a vendor
branch you get commits/code/history/whatever in your own repo and
don't depend on anyone anymore after you committed, while using
svn:externals you are dependant on company B for each access to
project/aaa involving svn. That's not necessarily a problem for you,
just something to consider in case of technical problems in company
B's network, they feel they don't like you anymore or whatever.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: is that possible the same code under two different subversion service provider?

[Les Mikesell]

On Fri, Feb 22, 2013 at 10:33 AM, frame  wrote:
>
>>
>> With this approach you loose history of new developments of
>> project/aaa and depend on company B with everything you are doing with
>> project/aaa and which is not already checked out somewhere, because
>> you don't merge any code back into your own repo. It's something which
>> I would consider really carefully.
>>
> Sorry, I don't quite understand what you said. Why will I loose the history
> of new developments of project/aaa? If I modify something in project/aaa and
> I check in, which will be in company B's repo. My partner abroad who only
> cares about project/aaa runs "svn update", he will pull out my change to his
> local area, together with the history. If he makes changes and check in his
> change(to company B's repo), I run "svn update" at the level of project/, I
> will get his new code(in aaa/) together with new code in bbb/ which is from
> company A's repo. I should be able to see his commit hisotry, right?
> I thought this is one of the ideal scenarios exploiting the power of svn
> externals definition.

Do you have write access to the company B repo?  If so and you need to
modify that part of the code, externals will do what you want - just
note that commits don't automatically recurse into parts pulled in via
externals, you have to commit them explicitly.   The 'vendor branch'
approach is for where you don't have write access and only get
periodic snapshots but want to make it look like a real history.   You
can use externals even with just read access to other repositories,
but then you can't commit back directly - but you might be able to
ship patches to someone with commit access.

-- 
   Les Mikesell
  lesmikes...@gmail.com

Re: Subversion 1.7 on RHEL 4.x

[Benson Margulies]

Yes, I succeeded by following the link that was sent with the configure
option.



On Fri, Feb 22, 2013 at 11:15 AM, Nico Kadel-Garcia wrote:

> Benson, hi.  Did you ever get Subversion 1.7 working well on RHEL  or
> CentOS 4.x? I took a glance back at my old RPM building tools for
> Subversion 1.6.20 and 1.7.8, and getting 1.7.8 built on RHEL 4 was a
> pain in the keister. In particular, I wound up having to build and
> install libserf to avoid dependency issues with out of date neon.
>
> I don't have a professional need for RHEL 4 anymore, but if you need
> Subverision 1.7 there and want to keep things tested, I'd be happy to
> help you get RPM building working well for that environment. If you
> can test it, we can get it into Repoforge "extras" and make your life
> easier in the future.
>

Working copy permissions changed by keyword substitution

[Joshua Root]

This seems like a bug to me, so I'm running it by the list as requested
on the web site.

My umask is 006, but I have changed the permissions on one of my svn
working copies so that it is world readable. Whenever I commit a file
that has property 'svn:keywords Id' and contains an Id line, the
permissions are changed back to the new file default as per the umask.
Committing files without svn:keywords leaves the permissions the way I
set them.

I'm trying to make a repro script, but keyword expansion doesn't seem to
be working right in the context of repro-template.sh. I've added this
where it said "This is where your reproduction recipe goes":

umask 006
chmod a+r iota
${SVN} propset svn:keywords Id iota
echo "# $Id$" >> iota
ls -l iota
${SVN} ci -m "Add Id" iota
ls -l iota

The "# $Id$" line changes into "# $", and what's worse, the permissions
don't change.

Please Cc me on replies.

Cheers,
Josh

Re: Working copy permissions changed by keyword substitution

[Daniel Shahaf]

Joshua Root wrote on Fri, Feb 22, 2013 at 22:23:57 +1100:
> This seems like a bug to me, so I'm running it by the list as requested
> on the web site.
> 
> My umask is 006, but I have changed the permissions on one of my svn
> working copies so that it is world readable. Whenever I commit a file
> that has property 'svn:keywords Id' and contains an Id line, the
> permissions are changed back to the new file default as per the umask.
> Committing files without svn:keywords leaves the permissions the way I
> set them.
> 
> I'm trying to make a repro script, but keyword expansion doesn't seem to
> be working right in the context of repro-template.sh. I've added this
> where it said "This is where your reproduction recipe goes":
> 

Please send the complete script in the future.  Yes, that's redundant,
but self-containedness trumps.

> umask 006
> chmod a+r iota
> ${SVN} propset svn:keywords Id iota
> echo "# $Id$" >> iota
> ls -l iota
> ${SVN} ci -m "Add Id" iota
> ls -l iota
> 
> The "# $Id$" line changes into "# $", and what's worse, the permissions

You need to use '' not "" to escape the $.  (see sh(1) man page)

As to your actual problem: I expect the permissions will be reset every
time an update or switch changes the file, even if it doesn't have
svn:keywords set.  Is it so?

> don't change.
> 
> Please Cc me on replies.
> 
> Cheers,
> Josh

Merge, reintegrate, and merge with tree conflicts

[James Hanley]

We are seeing merge tree conflicts where I believe svn is not working
as expected.  I'm not entirely sure if this is due to a lack of
understanding for proper use on our part, but it was my understanding
that reintegrate was to be used when pulling changes from a branch and
pushing them into the copied from branch.

The problem can be reproduced by creating a branch, add and committing
a new directory within the branch, reintegrating the changes to the
originating branch, then merging any new changes from the originating
branch into the branch with the changes.

I've included the following script to regenerate the issue two
different ways - the first is the most simple way I can think of the
reproduce it, and the later is a simulated structure of how we are
using svn and how I found it.

Any advice?
-Jim


enduceTreeConflict.sh
Description: Bourne shell script

Re: Merge, reintegrate, and merge with tree conflicts

[Matthew Pounsett]

On 2013/02/22, at 14:15, James Hanley wrote:

> We are seeing merge tree conflicts where I believe svn is not working
> as expected.  I'm not entirely sure if this is due to a lack of
> understanding for proper use on our part, but it was my understanding
> that reintegrate was to be used when pulling changes from a branch and
> pushing them into the copied from branch.

I asked about this a couple of weeks ago[1] as well.  The explanation I got[2] 
was that once you've done a --reintegrate, the source of that merge is a dead 
branch, and cannot be used again.  You can demonstrate this much simpler this 
way:

cd branches
svn cp ^/trunk ./mybranch
cd mybranch
mkdir foo
svn add foo
svn commit -m "added foo to mybranch"
cd ../../trunk
svn merge --reintegrate ^/branches/mybranch
cd ../branches/mybranch
svn merge ^/trunk

As soon as the --reintegrate is done, ^/branches/mybranch is dead.


[1] 

[2] 

Re: Working copy permissions changed by keyword substitution

[Joshua Root]

On 2013-2-23 05:30 , Daniel Shahaf wrote:
> You need to use '' not "" to escape the $.  (see sh(1) man page)

Argh, I knew that, but it just didn't register. Thanks.

> As to your actual problem: I expect the permissions will be reset every
> time an update or switch changes the file, even if it doesn't have
> svn:keywords set.  Is it so?

No, only files in which keyword substitution happens have their
permissions changed. (I've only actually tested with Id since that's all
my normal workflow uses.)

Full, working repro script attached. I'm on OS X 10.7.5 using svn 1.7.8 BTW.

- Josh
(Please Cc me on replies.)


repro.sh
Description: Bourne shell script