On Thursday 06 Apr 2006 3:20 am, you wrote:
> Madan U S <madan@collab.net> wrote:
> >>> [[[
> >>> Allow multiple 'svnmerge init' commands (with differing copyfrom
> >>> parameters, of course) in a single revision.
> >>>
> >>> * contrib/client-side/svnmerge.py
> >>> (check_dir_clean): Modified to error out, only if the change is
> >>> NOT just another modification of the svnmerge-integrated property.
> >>> IOW, dont error out, if the only other change in the working copy
> >>> is an svnmerge-integrated property change.
> >>> ]]]
> >>
> >> What's the rationale of this patch? You can use --force to achieve
> >> the
> >> same.
> >
> > When using a svnmerge command, a --force would be to override a
> > non-svnmerge action. The user should not have to worry about the
> > changes that are made by svnmerge. He has to use --force only when
> > some unrelated change has happened and he has to override that
> > change.
> > Also, by doing this, the user can issue a series of 'svnmerge init'
> > (on various branches) before doing a commit. This helps keep down the
> > number of empty revisions. This also makes it simpler to use the
> > 'svnmerge init' command (Otherwise, the user has to do a 'svnmerge
> > init', followed by a series of 'svnmerge init --force') during the
> > course a simple admin task - setting up a repository for merge
> > tracking for the first time.
>
> Thanks for the explanation, +1 on the concept. As for the patch itself, I'd
> rather it use "svn diff -N" to avoid stats on potentially thousands of
> files for no reason.
You are sooo right.
> Then, you should verify that it doesn't crash if the
> svn diff output is empty.
Done that. (in that case the 'svn st' output would be empty too, and a 'svn
diff' will not be invoked)
> And you should also add a testcase (and/or fix
> the existing testcases if they now don't work as expected).
yes. over some time, I will add test cases to this.
Regards,
Madan.
Received on Thu Apr 6 08:27:36 2006