Quoth Magnus Andersen <mailto:mag.andersen@gmail.com>:
> Devoploper 1 is working in /var/www/intranet/q2o and have
> made changes that needs to go to test and then to production.
>
> Developer 2 is working in /var/www/intranet/test and have
> done some testing that is not ready for test or production.
> In fact, if this is push to test or production it will mess
> the current working test directory up.
>
> I need for devloper 1 to be able to move his stuff to a
> test/prod environment that is versioned, but I can't do the
> whole trunk since that would bring the changes in test with
> it and mess the "test" program that is currently in test/production
> up.
If I'm understanding you correctly, then that is readily doable.
I'm assuming here that those folders are already part of a working copy,
and that each developer is working in their own private working copies,
but have each already committed some changes (some of which you don't
want to include). Developer 1 at least has already committed everything
that you want to include, and you are either working from a third
working copy or are developer 1 yourself -- but either way, you have no
local modifications.
If you only want that single folder (ie. intranet/q2o), and nothing
else, then just copy that as your tag/branch. You don't have to copy
the whole trunk if you don't want to. (Though as I said earlier, any
post-commit scripts you've created might make assumptions about what has
been included, so you need to be careful if you're using that sort of
thing.)
If you want your tag/branch to include other folders (including what
intranet/test *before* developer 2 started working on it) then:
1. using svn log, find out the revision number of the first commit that
developer 2 made to the test folder (which presumably you don't want to
include in your tag).
2. copy the trunk to your tag/branch, specifying a revision that's one
less than developer 2's commits.
3. switch to the branch, then to the q2o subfolder, and merge from there
all of developer 1's commits since that same revision number, and hope
they haven't changed anything elsewhere. (alternatively, you could
stay in the branch root and simply merge everything except dev 2's
revisions, but unless you're using a merge tool like svnmerge.py then
that can get painful.)
You can use svnmerge.py to help out with some of the merging, and keep
track of which revisions have been included where.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 28 08:29:16 2006