[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: coping with different coding styles

From: Gavin Lambert <gavinl_at_compacsort.com>
Date: 2005-12-02 01:20:05 CET

Quoth Dmitry Beransky <mailto:db01@dembel.org>:
> I understand that I may need to adopt a coding standard in
> order to be compatible with Subversion. But that was exactly
> my question: is there a way to make Subversion work the way I
> want? If the answer is an absolute and definite 'No' then I'll
> have to change my ways. But then this smells to me as the case
> of making a developer jump through hoops because tool aren't
> flexible enough instead of having the tools making the
> developer's life easier (not that Subversion hasn't eased
> our lives by so much already :-), but we always want more).

Your IDE can be reasonably expected to understand your code and be able
to reformat it (after all, it can syntax-highlight it).

It's less reasonable to expect that of Subversion, since it has to be
able to understand ANYthing you commit, no matter what language it's
written in -- even non-code files.

Still, if you really want to then I think it'd be possible for you to
write a commit hook that would reformat the files to the "correct"
style. Then the developer could commit in whatever style they wanted
and it'd get reformatted to a unified style automatically. But it's far
easier just to get people used to a single coding standard. (It's also
generally regarded as impolite for a version-control system to store a
modified version of what you're committing, rather than keeping it
verbatim.)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 2 01:27:00 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.