# svn up
C Arus
# svn merge -rfirst_lion:last_lion .
# svn resolved Arus
Resolved conflicted state of 'Arus'
# svn -m 'Voltron saved the day' ci
That is all
# svn up
C Arus
# svn merge -rfirst_lion:last_lion .
# svn resolved Arus
Resolved conflicted state of 'Arus'
# svn -m 'Voltron saved the day' ci
That is all
It's interesting to me that you put the option m before ci, but after for merge 😉
I think about commands, generally, as "doing what to what" the message applies to the ci and the ci applies to the files. the merge applies to the revisions and the revision merge applies to .
also
ising -m 'message' BEFORE ci files makes sure that I don't forget to add a meaningful message since its the very first thing i do.
Your merge could be 'svn merge . -rfirst_lion:last_lion' then?
Interesting, I think of the command is the whole command being 'svn ci' and all the parameters being after. How I imagine it is processed.
Being able to order it 'svn -m' seems like sugar, and I don't image less well written commands are as flexible.
actually. most programs written as vli utils with standard getopt style Luba allow you to specify things in any order. on Linux at least. normally only one arg is positionally dependant if any.