Re: Shared source best practices

[Nick Beadman <ni...@xinet.com>]

Stuart,

Thanks for the respose, I am surprised that no-one else jumped in  
because this seems to be something that everyone would have to deal  
with.

I agree that code in each repository should be developed separately,  
and although a top level commit does not effect the svn:externals if  
you commit inside that directory then it is committed even though the  
svn:externals might specify a revision. On the next check out (at the  
top level) then those changes will be lost which is quite a shock.

At this point, I think that I am going to try and patch this up by:

1) Prefixing all svn:externals directories with "EXT_" and having all  
common code in that folder and no subfolders
2) Marking all common code with svn:needs-lock to help enforce not  
changing things
3) Using the current version of the common code in the projects / 
truck and including a shell script in every project to create  
releases. The shell script will change the svn:externals properties  
to a single revision

Of course, it would be great if Subversion would understand  
svn:externals better than as just a pointer to some other repository....

Nick

On May 31, 2006, at 11:42 am, Stuart Celarier wrote:

> It seems to me that putting code in separate repositories probably  
> means
> that code in each repository should be developed separately,  
> regardless
> of how you combine the repositories into working copies using
> svn:externals. After all, you cannot commit a change set contains
> changes to multiple repositories. IIRC, you cannot even commit a  
> change
> set that spans an externals definition boundary, even if only on
> repository is involved.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Shared source best practices

[Nick Beadman <ni...@xinet.com>]

Ryan,

>> I think I am going to go ahead and use revision-less external  
>> definitions for project trunks and then use scripting so that when  
>> a release is branched the external definition is converted to one  
>> that specifies a revision.
>
> I believe that's exactly what the svncopy perl script does, though  
> I haven't used it myself.

Bingo ! This is the piece of information I was missing. Thanks so  
much for pointing it out, with this script makes creating releases  
easy. Now all I have to do is test it in my environment.

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Shared source best practices

[Ryan Schmidt <su...@ryandesign.com>]

On Jun 2, 2006, at 20:05, Nick Beadman wrote:

>> When I include an external library into a project, I link not to a  
>> revision of the library but to a branch of it. I've decided that  
>> within a branch, I will only make backwards-compatible changes to  
>> my library. If I later want to make a backwards-incompatible  
>> change, I will first make a new branch for that, so that older  
>> projects will not be impacted by the change. Older projects can be  
>> updated to use the library's new branch as necessary by changing  
>> their external link and fixing all usage of the library to match  
>> the new conventions.
>
> This is an interesting idea, but by allowing yourself to make any  
> change to the common code you are making it impossible to build an  
> older release of a product exactly as it was when shipped. Although  
> given that you are only likely to building an older release to make  
> a fix, it may be acceptable to pick up new common code as the  
> product will be tested before the fix is released.
>
> In fact I hadn't given any thought to using branches for common  
> code usage and it is possible to create a branch in the common code  
> for each product and version which would give you the ability to  
> get the code back exactly as shipped. Of course, this would mean  
> many branches and the common code base would probably become unwieldy.

True -- I can't go back exactly to a released state this way. (We  
haven't needed to do this yet.) If that's paramount, then combining  
the branch with a revision is an idea, or you could tag the branch at  
each relevant stage, and link to the tagged library in the external  
definition. I think that would be a perfectly reasonable use of tags,  
and shouldn't be any more unweildy than tags in any other project.


> I think I am going to go ahead and use revision-less external  
> definitions for project trunks and then use scripting so that when  
> a release is branched the external definition is converted to one  
> that specifies a revision.

I believe that's exactly what the svncopy perl script does, though I  
haven't used it myself.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Shared source best practices

[Nick Beadman <ni...@xinet.com>]

Ryan,

Thanks for the response! You bring up some very interesting points.

>> I agree that code in each repository should be developed  
>> separately, and although a top level commit does not effect the  
>> svn:externals if you commit inside that directory then it is  
>> committed even though the svn:externals might specify a revision.  
>> On the next check out (at the top level) then those changes will  
>> be lost which is quite a shock.
>
> It should come as no particular shock to you. If your external says  
> to use revision 5 of the thing, then it will quite logically do so.  
> If you have gone into the external's working copy, updated it to  
> HEAD and committed changes, and now want these to be used in  
> (everybody else's working copy of) the project, then the external  
> definition should be updated to reference the new revision number.

Now that you put it like that, I understand why you would want the  
behavior as it is. Of course, Subversion could be friendlier in  
helping make sure the external definition is updated but this method  
is definitely useful.

> Of course you now have to contend with the fact that if you were  
> pointing at revision 5 of the library before, and now committed a  
> change and it's revision 42, you should probably see if there were  
> any changes between 5 and 42 that you didn't want to include.

Of course, but then again you would probably want to pick up those  
fixes anyway. At least by doing the update you are making a conscious  
decision and therefore can think of the consequences. Most of the  
time (at least in my case) the common code is kept backwards- 
compatible and I am either fixing bugs, adding more common code or  
making it compile with a new environment (Xcode vs. CodeWarrior vs  
Visual Studio).

> When I include an external library into a project, I link not to a  
> revision of the library but to a branch of it. I've decided that  
> within a branch, I will only make backwards-compatible changes to  
> my library. If I later want to make a backwards-incompatible  
> change, I will first make a new branch for that, so that older  
> projects will not be impacted by the change. Older projects can be  
> updated to use the library's new branch as necessary by changing  
> their external link and fixing all usage of the library to match  
> the new conventions.

This is an interesting idea, but by allowing yourself to make any  
change to the common code you are making it impossible to build an  
older release of a product exactly as it was when shipped. Although  
given that you are only likely to building an older release to make a  
fix, it may be acceptable to pick up new common code as the product  
will be tested before the fix is released.

In fact I hadn't given any thought to using branches for common code  
usage and it is possible to create a branch in the common code for  
each product and version which would give you the ability to get the  
code back exactly as shipped. Of course, this would mean many  
branches and the common code base would probably become unwieldy.

I think I am going to go ahead and use revision-less external  
definitions for project trunks and then use scripting so that when a  
release is branched the external definition is converted to one that  
specifies a revision.

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Shared source best practices

[Ryan Schmidt <su...@ryandesign.com>]

On Jun 1, 2006, at 19:07, Nick Beadman wrote:

> I agree that code in each repository should be developed  
> separately, and although a top level commit does not effect the  
> svn:externals if you commit inside that directory then it is  
> committed even though the svn:externals might specify a revision.  
> On the next check out (at the top level) then those changes will be  
> lost which is quite a shock.

It should come as no particular shock to you. If your external says  
to use revision 5 of the thing, then it will quite logically do so.  
If you have gone into the external's working copy, updated it to HEAD  
and committed changes, and now want these to be used in (everybody  
else's working copy of) the project, then the external definition  
should be updated to reference the new revision number.

Of course you now have to contend with the fact that if you were  
pointing at revision 5 of the library before, and now committed a  
change and it's revision 42, you should probably see if there were  
any changes between 5 and 42 that you didn't want to include.

When I include an external library into a project, I link not to a  
revision of the library but to a branch of it. I've decided that  
within a branch, I will only make backwards-compatible changes to my  
library. If I later want to make a backwards-incompatible change, I  
will first make a new branch for that, so that older projects will  
not be impacted by the change. Older projects can be updated to use  
the library's new branch as necessary by changing their external link  
and fixing all usage of the library to match the new conventions.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org