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]
________________________________
------------------------------------
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:-
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 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.
----------------------------------------------------
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/
--- the following projects are mostly class libraries and are shared by many full projects -----
My projectA solution also contains the shared "library" projects listed above. As a test I did the following:
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/
These "externals" folders would just be links to the actual shared projects located in the "PMD Repository/Tools/" directory.
Thanks again Keith,
Library\Tags\Release\1.0.0\ Current version of the shared 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.
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.
#####################################################################################
------------------------------------------------------
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
|
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.