I will try to give you some hints backed by my personal experience.
One of my teammates, although experienced, does not really understand
SVN. Naturally, blank areas on his mental map depicting oceans of SVN
cause him to adopt rather strange usage patterns.
For example, he had declared a policy of "1 SVN commit per day per
developer" because otherwise "the server would soon run out of disk
space". When I explained him that SVN commits are deltas, not full
copies, he responded with doubt and even today I'm not entirely sure
if he understands what it means.
Even if disk space were an issue, you could always commit a lot of files at once, so I think what he suggests is the wrong solution. Furthermore, it is possible to waste a lot of space by checking in large binary files because SVN does not store deltas for binary files.
One check-in per day is also bad because it forces you to commit changes that do not belong together, e.g. in case you fix more than one bug per day.
The solution we have adopted in our company is that there is a filter rejecting any commit containing binary files. We can force the commit by using a special keyword in the check-in comment (we have to show SVN that we know what we are doing). Once in a year or two a project manager archives old branches and removes them from the repository. With this strategy we do not have space problems that I know of (our repository supports several different projects and has over 100000 revisions).
Summarizing, you could tell him that you agree with him that disk space is an important issue but, on the other hand, point out
- the importance of feature-related check-ins instead of one monolithic daily check in;
- the fact that by checking in one large binary file per day, one could fill the disk anyway.
Then you could suggest that you have a meeting (possibly with other developers or system administrators as well) to discuss strategies for keeping disk space usage under control (e.g. binary-file filters, regular backup and clean up of old unused branches).
We also had a heated argument about whether to include Eclipse
.project configuration in SVN. My teammate insisted we should,
although it has caused numerous pointless conflicts. I was against
keeping individual developer configuration files in SVN. Finally, it
turned out that my teammate had a practice of re-checkouting the
entire source tree after every commit to just make sure "code
committed into repository works". That was the reason he was so
adamant in keeping the project configuration in SVN - so it would be
easy to re-import the project. When I explained that commit
synchronizes working copy to remote byte-by-byte which makes
re-checkout unnecessary, my teammate responded with doubt again and
eventually waved the whole issue off as insignificant.
In my opinion, our team wastes time by resolving SVN conflicts in
project configuration files which contain only developer-specific
settings that need not be shared to SCM at all. All this mess because
someone tailored the process around incorrect assumptions.
Do you use a build server? We have a build server that checks out the complete project and compiles it every night. The next morning the testers have a ready-to-test installer of the product (if the master build ran correctly) and we (the developers) have a build report with all the warnings (and errors, in case there are any). Of course, you need to set up standard configuration files for the build server and check them in. Each developer can then check them out along with the rest of the project, but they are not allowed to check in any local changes.
In this scenario you address his need to be able to check out the complete project and build it at any time. You also avoid spending time to merge changes that should not have been checked in the first place because they are not part of the product: the product is the master build, and that must be kept clean. If someone breaks the master build (e.g. checking in his own .project file) you can revert the changes or force that developer to fix the problem.
Maybe if he brings up the issue again, you can again suggest to have a meeting (possibly with other developers) and find a common strategy together.
How can I convince a teammate, who sees oneself as senior, to get a
better understanding of SVN basics?
I think the best strategy would be to avoid bringing the conflict to a personal level and rather discussing the issues at hand and possible solutions. If you have the impression that he is looking for a personal confrontation, here are some suggestions (again, from personal experience):
- How is your team dynamics? Are your other colleagues having a similar experience with this team mate? There are a lot of small, not too explicit hints that a team can give to one of its members to discourage certain behaviours (small jokes or observations) and encourage constructive confrontation (proposing a meeting, or bringing up a topic informally during a coffee break). Sometimes a good team can quickly isolate a disturbing element and bring things back to normal.
- How good is your personnel management? We had one conflict case in our company and the head of personnel had to intervene to clear the situation. It was not nice, but sometimes the working atmosphere deteriorates so much that it will not get better by itself. I hope this is not your case (I do not have the impression it has gotten that far yet) but it is always good to know if you have a good personnel administration or if you have to solve conflicts on your own.
Why am I writing this? You say that you want to "convince a teammate, who sees oneself as senior, to get a better understanding of SVN basics". To me it sounds like the conflict might be getting too personal. Some psychologists maintain that 70% of our communication is at the emotional level, if this level is not working, then people stop speaking about facts because they are too busy dealing with emotions.
So, besides explaining your points, you could also try doing something to improve the communication. Inviting for a coffee or to have a lunch break together, having a short conversation about a topic that is not related to work, etc, can improve the communication and bring your colleague's attention back to the important facts that you want him to understand. If he accepts this kind of communication, then maybe the conflicts that you had so far were related to the fact that you do not know each other well and there were some small misunderstandings but he is probably open to build a constructive collaboration. If he refuses, then there might be a deeper hostility on his side.
In this case, I think you should wait until your roles become clearer. If you team mate does not officially have a higher rank than yours he has no point getting irritated at your attempts to improve things. With time he will have to accept it or make a fool out of himself if he keeps trying to show he knows better.
If he does have a higher rank, you should find a way to let him understand that this is not under discussion: your observations are aimed at improving the productivity and not at undermining his position, this must be 100% clear.
When the roles have been clarified, if he still cannot accept constructive suggestions or criticism, then he really must have some problem with self-esteem or something like that.
So if all the strategies above fail and you keep feeling (very) frustrated, I am afraid the only reasonable thing to do will be to pack your things and look for a better place. I made this experience three years ago and found a much better company in which I am very satisfied now. Maybe this is not your case (I hope not of course) but try to understand this point too.
Just my 2 cents.