drKzs, Svnmerge, like any other subversion merge (and pretty much everything in subversion) is based on revisions, so its important to start thinking about these changes in terms of revisions rather than the specific changes to files and directories within those revisions.
so the unique solution to merge a part of the branch, is to use the -r > option with revision number ? Yes. If you are interested only in certain changes, you must determine and merge only the specific revisions you want. After an svnmerge, i MUST commit all modifications of that merge, otherwise > they won't be seen at the next svnmerge ? Yes, but not just for that reason. You'll generally want to make sure to commit all of the resulting changes from a merge (after resolving any conflicts), including all property changes. If you merge a revision without committing all of the changes, svnmerge (and subversion itself) will think changes have been merged that actually have not. This will be extremely confusing to subversion, svnmerge, and any humans attempting to track the history of changes in the future. Here are a few things I've found useful until you get the hang of it: Do an 'svnmerge avail' and check the log of those revisions in the source branch to make sure things look correct. This is also how you want to determine which revisions you do and don't want to merge. The format of the svnmerge output is compatible with the merge -r parameter as well, so if you want to merge up to a given revision, say, you can cut and paste from the output of svnmerge avail. If a merge goes bad, it's easily undone. "svn revert . -R" will roll back all of the changes except additions, which will be exposed with "svn st". Simply delete the untracked files and directories and do an "svn up" and you should`be back where you were. I wind up using "svn pl -v" a lot.. Hope this helps.. --Bill On Mon, Jul 23, 2012 at 9:55 AM, drkmkzs <[email protected]> wrote: > Hello, > > I've just begun to use svnmerge, and I had some little problems, > surely due to my misusing, or my misunderstanding :) > > We have a trunk branch, and we branched a devel branch from it. > We work on the devel branch, commit, etc etc... Then when want to merge. > > We went the trunk local repository, ensured it's up-to-date, and did > svnmerge. > All was fine, we could see all modifications on the local repository. > > The problem was at the next step : > > we believed we could commit just the modifications on some files we > want, so we just committed some files. For the rest of the files - that > were merged but we didn't want to commit - we just replaced them with the > head version (i think the bad usage is here) > > Then we continue to work on the devel. > > Then we wanted to process a second merge. But after the svnmerge, all > modifications that had not been committed at the first merge were not > merged. It was like svnmerge had skipped them... > To get them back, i had to uninit the trunk branch, and do the process > again. > > Is my understanding correct ? After an svnmerge, i MUST commit all > modifications of that merge, otherwise they won't be seen at the next > svnmerge ? > => so the unique solution to merge a part of the branch, is to use the > -r option with revision number ? > > Thanx a lot, > and sorry for my english, i did my best ;) > > drKzs > > _______________________________________________ > Svnmerge mailing list > [email protected] > http://www.orcaware.com/mailman/listinfo/svnmerge >
_______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
