[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Checkouts - I think I've been doing it wrong for 3 years!

From: Keith Moore <Keith.Moore_at_securency.com>
Date: Mon, 17 Aug 2009 09:56:19 +1000

From: Steve Klett [mailto:sklett_at_pmddirect.com]
Sent: Saturday, August 15, 2009 2:12 PM
To: Keith Moore; users_at_subversion.tigris.org
Subject: RE: Checkouts - I think I've been doing it wrong for 3 years!

________________________________
From: Keith Moore [mailto:Keith.Moore_at_securency.com]
Sent: Thursday, August 13, 2009 8:55 PM
To: users_at_subversion.tigris.org
Subject: RE: Checkouts - I think I've been doing it wrong for 3 years!

------------------------------------
Hi Steve,

You more or less have the jist of it. Where I work we have multiple projects all with a similar structure, such as:-

In our repository:-
Project1/
Project1/Trunk/
Project1/Trunk/* source code whatever
Project1/Branches/
Project1/Branches/Re-Release
Project1/Tags/
Project1/Tags/Release/
Project1/Tags/Release/1.0.0 copy of the trunk at the time of the release
Project1/Tags/Release/1.1.0 etc.

We're a small team so we do all development on Trunk and do a copy (a branch is merely a copy in subversion) from there to "Tags/Release/*version number*". We copy the _whole_ of the trunk to the new folder. We also have a policy that you cannot change anything in the Tags directory, except copies of course.

In circumstances where we need to bug fix a release we copy the _Tags_ directory to the Branches/Re-Release folder, for example we'd copy Project1/Tags/Release/1.0.0/ to Project1/Branches/Re-Release/1.0/. We make the change in the branches directory and then do a new release, to Project1/Tags/Release/1.0.1/. This is not the recommended way from the subversion book and I believe we could do it better but this isn't giving us too much pain at this stage so I see no reason to change it.

Now, with regard to working copies and switching: We allow developers to checkout a project to any [local] directory on their development machine. They _must_, however, checkout the entire project whether that is trunk, a release or a branch. So using the example they would checkout Project1/Trunk to [on Windows] C:\Development\Project1\Trunk\, or Project1/Tags/Release/1.0.0 to C:\Development\Project1\Release-1.0.0\. It is up to the developer to manage their working copies and local file system. We agree to use the ProjectName/Trunk or ProjectName/Release-x.y.z format for working copies but it isn't enforced. When using this standard we find that we very rarely need to switch the working copy.

Working copy switching - when you checkout a working copy it is linked the location in the repository it was checked out from, switching means changing the locations to which a working copy points.

An example using Project1.

I checkout Project1/Trunk to C:\Development\Project1
I make some changes and now I'm ready to release so I update my working copy, resolve any conflicts, build, test, etc. and then commit my changes to the repository.
Next I svn copy Project1/Trunk/ to Project1/Branches/Dev1/CrazyIdea/ because I have an idea to do something a bit different but I don't want to effect the Trunk code base.
I've copied but my working copy still 'points' to Project1/Trunk/ so I 'switch' my working copy to point to Project1/Branches/Dev1/CrazyIdea/ and then svn update to make sure the working copy is up to date.
Now when I make changes to this working copy and commit them they go to the Project1/Branches/Dev1/CrazyIdea part of the repository rather than trunk.
When I finish my changes on CrazyIdea, if they are good and they work I can 'merge' my changes back into trunk and 'switch' my working copy back to trunk. If my changes weren't a good idea I can just delete my branch and working copy.

I think switching only really makes sense in a scenario where you svn copy your working copy and then want to start working on that new subversion copy. In theory you can switch any working copy to any other part of the repository, but because of the changes between trees and files it will result in your working copy being a complete mess (someone correct me if I'm wrong about this).

Hopefully that's cleared it up for, at least a little.
Keith Moore.

 ----------------------------------------------------
Hi Keith,

Man, thanks for the great reply! Lots of info, I really appreciate you taking the time to write all this up.

Your email has cleared some things up for me and I now see that I was thinking about working copies a bit incorrectly. Your last example with your "CrazyIdea" branch is exactly like my situation now; I want to experiment with something but I know I will need to update the trunk and release a version before I finish my crazy experiment.

If you don't mind I like to ask a few more questions and kinda think through some other challenges I foresee.

My repository is something like this:

PMD Repository/
PMD Repository/Tools/
PMD Repository/Tools/ProjectA/ <------ Project A is solution with many sub projects
PMD Repository/Tools/ProjectA/tunk/
PMD Repository/Tools/ProjectA/branches/
PMD Repository/Tools/ProjectA/branches/CrazyNewFeature
PMD Repository/Tools/ProjectB/ <------ Project B is solution with many sub projects
PMD Repository/Tools/ProjectB/tunk/
PMD Repository/Tools/ProjectB/branches/

--- the following projects are mostly class libraries and are shared by many full projects -----
PMD Repository/Tools/BusinessEntities/
PMD Repository/Tools/Library/
PMD Repository/Tools/WinFormControls/
PMD Repository/Tools/FileUtils/
PMD Repository/Tools/TestBench
PMD Repository/Tools/OtherUtilities

My projectA solution also contains the shared "library" projects listed above. As a test I did the following:
1. created the trunk/tags/branches structure under "ProjectA"
2. moved all of "ProjectA" under trunk and committed
3. branched trunk to a new branch and checked it out

When I opened the branch solution (Visual Studio) I received an error that multiple projects could not be loaded (all the shared projects). So the solution must have been using relative paths because now I can see that it's looking for the shared projects in "PMD Repository\Tools\ProjectA\branches\someLibraryProject". I've read about externals a bit and suspect this may be what I need to use but I'm not positive. It seems that if I use externals I would need to create a folder under ProjectA that would contain all the shared externals. Something like:

PMD Repository/
PMD Repository/Tools/
PMD Repository/Tools/ProjectA/
PMD Repository/Tools/ProjectA/tunk/externals/ <-- externals
PMD Repository/Tools/ProjectA/branches/
PMD Repository/Tools/ProjectA/branches/CrazyNewFeature/externals/ <-- externals

These "externals" folders would just be links to the actual shared projects located in the "PMD Repository/Tools/" directory.
Oh man, now I'm getting confused! I'm going to stop here and hope that what I've written so far makes sense. It's not common for me to struggle with something like this, I must be thinking about it all wrong. I feel like I'm close, I just need a little more clarification (I hope).

Thanks again Keith,
Steve
------------------------------------------------------------------------
Steve, the simplest option may be not to use branches and tags at all, as David suggests. However, we feel a little more comfortable using them at our shop. We also have shared libraries in our repository and yes we do use externals to bring those libraries into the projects that requires them. A structure something like:-

Library\Tags\Release\1.0.0\ Current version of the shared library
Library\Trunk\
Project1\Tags\Release\1.0.0\
Project1\Tags\Release\1.0.0\Externals\
Project1\Trunk\ Development line for Project1 - contains source code for Project1 *only*
Project1\Trunk\Externals\ Directory with the svn:externals property
Project1\Trunk\Externals\Library\ Directory for each external shared library
Project2\Tags\Release\1.0.0\
Project2\Trunk\ Another project that makes use of a shared library
Project2\Trunk\Externals
Project2\Trunk\Externals\Library\

Our in-house rules around externals is that they *must* reference a release of the shared library and the external URL *must* contain the revision number. Again, I'm not advocating this as the best solution, this works for us although I would say that we aren't completely happy with it. If the code in the external changes it means we have to do a release of the external, but we want to change it because it's used in the main project, this is less than ideal and causes confusion and delay.
As for your implied question regarding the project references of shared libraries, our project structure means that the externals are in the same directory, with regard to the VS solution, for *every* project. If we branch, the externals must also be branched, and a branch must always be for the full project, i.e. from the Trunk directory.

When we started out we had a much simpler approach to all of this, i.e. one project, no shared libraries, etc. As the source code became more complex the [original] model wasn't working for us, so we changed it. When we got even more complex we changed it again, and I'm sure in the future we'll change it some more. What I'm trying to say is, only make it as complex as it needs to be right now. You can always change your strategy later.

Keith.

#####################################################################################
Attention:
The information contained in this message and or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact the sender and
delete the material from any system and destroy any copies.
#####################################################################################

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2384168

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-17 01:58:40 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.