> 2) Before "committing" our changes (it is not really a commit since
> we are not using version control software but it is equivalent) we use
> a "differencing" software like Beyond Compare: it shows all the
> changes made for both tasks and allows in place editing - we then use
> the in place editing feature to add a little tag written like a
> comment like /* FCT_A */ or /* BUG_B*/ at each block of code which was
> added or modified. And usually at the top of the file where the most
> changes have been made we add a longer description of the feature,
> like
> /* FCT_A: Developer DDD - mm/dd/yy - Implemented functionality A */
It is possible to do the same with svn (or any other tool). If I make
this _mistake_ to mix up several changes I do the following:
svn diff file1 > patch1
cp patch1 patch2
cp file1 file1.backup
svn revert file1
edit patch1 patch2 to separate the differences
patch < patch1
svn commit -m 'function A'
patch < patch2
# sure is sure: diff file1 file1.backup
svn commit -m 'bugfix B'
It can be a bit more complex with several files but not really hard in
practice. It worth the effort to have nice small separated commits.
It's equivalent to your old way. Both have the risk that you mix up
your changesets. Separating changesets is unnecessary work, you should
do something smarter.
1. You can maintain two local copies, one for normal development, the
other for smaller high priority changes that can interrupt your normal
work.
2. You also can save your current changes, revert, do the bugfix,
restore your previous files. (patch is your friend)
3. You can create a branch, commit your changes there. Switch to trunk,
do the bugfix, switch back to the branch, finish your change, merge to
trunk.
WP
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 29 10:47:42 2006