On Tue, May 27, 2008 at 8:22 AM, jpyork <jp_york_at_hotmail.com> wrote:
> I am trying to find out if it is possible or the best way to have a
> "placeholder" in subversion. The issue is that developers want a place to
> check in there code without checking it into the actual repository. Kind of
> a way to save there code off there pc, so that if something happens to there
> pc there changes are not lost. The only way I thought of doing this was
> setting up a part like the following
> Repository name - Branches --> Developer 1
> - Tags Developer 2
> - Trunk Developer 3
> In each Developers part of this repository they could have folders with the
> name of each project in it and have there changes in there.
> Is this the best or only way to do this?
> Any other suggestions?
We have about 60 developers in three geographically disparate offices
working on a large product suite within a larger corporate platform.
We have the following structure under our repository root:
/branches/build/ReleaseSeries1.0 // For
consolidation and testing of features for a given prospective release
/ReleaseSeries1.0SP1 // a
release series can be a major, minor, service pack, or enhancement
pack release.
/ReleaseSeries1.1 //
prior to shipping, changes in a given release series are automatically
merged forward to subsequent series.
/ReleaseSeries2.0 //
once a release ships, new changes are made only in subsequent series,
and forward merging stops.
...
// after a release ships, hotfix changes may be back-merged and
hotfixes are built from the HEAD of that branch.
/ReleaseSeriesN
/feature/ReleaseSeriesX/Feature1 // For
development of a feature intended for release series X
/Feature2
...
/FeatureN
/personal/JoeDeveloper/JoeBranch1 // Contains
anything user joe.developer wants to put there... mostly contains
snapshots of Joe's working copies
...
// Client-side scripts also back up the pre and post branches of a
branch-with-working-copy-changes to this directory to aid repo-browser
diffs.
/JoeBranchN
/tags/
// Contains only snapshots of automatic builds off of each release
series and named aliases for shipped release builds; scripted to be
write-once.
/meta/
// For branch-independent development of scripts and definition files
specific to this particular svn repository
(Note the lack of a /trunk - this has yet to cause any difficulty
whatsoever. Is anyone aware of a reason why /trunk is really needed if
you have release series "trunk branches"?)
Note: there is also significant complexity within a given branch,
including language and platform subdirectories and multiple projects
with subsets of the shared libraries.
We are currently using scripts to pare down developer working copies,
but with the advent of 1.5, we're switching to the use of relative
externals and sparse checkouts.
The bash version of our current solution uses "for excluded_directory
in exclude_list do ; svn switch /meta/empty_dir excluded_directory ;
done"...
This does mean that snapshots are usually of a subset of the original branch.
Feature branches and release branches are created for the entire tree
structure under a release series. This allows one group (for example)
to do the core C++ development,
and another group to handle related changes to the Java, C#, or Python
API code, for the same feature or release, without both groups needing
to check out the same massive
working copy. Obviously, the snapshots are only going to involve the
relevant portion of the tree that was in the working copy, which means
merging a snapshot into a feature
requires excluding the switched elements from the merge... hence the
pre- and post- snapshots, which can be used to get an accurate change
set.
For your scenario, I would say the /branches/personal/DeveloperN/*
model would work pretty well...
You might want to split /branches/personal/ into /branches/backup/ and
/branches/personal/, just to reduce clutter. I wish I had...
One of the nicest things about subversion is the cheapness of creating
a branch. Almost (not quite, you still need a call to the server) as
cheap as hg or git.
We strongly encourage the liberal use of branches, both for backup
("snapshot branches") and for feature development, even one-man
feature development.
We've had very few incidents with dead drives, though snapshot
branches have caused us to be less paranoid - we got rid of the
RAID-on-all-developer-boxes rule.
The biggest advantages of branches are 1) the "well, it almost works,
but this last part might break it - let me commit it before I proceed"
mindset, and
2) the "OK, this works on Windows x64... does it also work on the
other 11 platforms and 5 compiler families that we need to support?"
analysis.
You do need to establish a sort of social attitude of "don't ever
judge a developer on anything (work related) that they commit to a
personal branch"...
One option is to have a subtree of each developer's personal branch
that is private, using the access control lists.
Then no-one need feel embarrassed about committing under-ripe code.
The other alternative is to have a sufficiently nurturing environment
that no-one feels embarrassed even if it is visible...
Good luck in working out a scheme that works for you. Discuss it with
a few of your more creative developers.
Once created, it'll have a lot of momentum, so getting it (mostly)
right early is definitely worthwhile.
Remember, Subversion is _very_ flexible when it comes to branch
structure, so stretch your imagination.
Also, it is wise to adopt a policy of avoiding spaces in branch names
if you are planning to write batch scripts that interact with
subversion on Windows.
While it is *possible* to work around the quote munching and space
delimiting issues, it isn't fun.
If you're feeling ambitious, consider setting up a parallel DVCS (I've
used mercurial - hg - for this) for snapshot management.
The graphical tools aren't all there, but it does work pretty well in
parallel to subversion, and I've found that for our purposes, DVCS
works much better as
an adjunct to centralized VCS than as a replacement for it. If a
developer has access to two systems, they can backup from one to the
other, and it is a
great way to get infinite undo, even locked to a local system. I've
been playing with hooking it up to save events on our IDEs...
Regards,
Nathan F. Yospe
Library Architect, MDM Core
SAP Labs, Los Angeles
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-27 19:03:06 CEST