________________________________
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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2383815
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-15 07:49:15 CEST