On Oct 11, 2006, at 05:16, Thomas Lehmann wrote:
> working on a project 'ABC' sometimes it's important to commit changes
> before end of this project to be able to undo failures...
> Each commit forces (of course) a new revision.
> --> one project is not necessarily one revision!
>
> Now: Someone orders to merge project 'ABC' from the 'development tree'
> to the 'release tree'!
> --> How?
> --> Do I've to remember all revisions for this project?
> --> Can I avoid merging changes of project 'XYZ'?
> (some files have been changed in both projects)
Some terminology issues: what you're calling a "tree", we usually
call a "branch". What you're calling a "project", we usually call a
"feature" or "issue" I suppose.
So it sounds like this might be a good time to not have a single
development branch, but a branch per feature/issue. Then you can keep
each feature's/issue's changes in its own branch, which can be merged
(or not) to the release branch.
Using branches is described in the book at http://svnbook.org
If you have already made all these unrelated changes on the
development branch and now want to merge them, separately from other
changes that have been made on the development branch, then yes, you
will have to merge each revision or range of revisions separately.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 13 23:57:45 2006