Subversionのインポート操作を禁止する方法

質問

Subversionのインポート操作を管理側で禁止する方法がありましたら、教えて下さい。
プログラマではない人も、Subversionを使ってもらって、ソースコードを管理しています。
しかし、「Checkout」と「Import」の意味を間違えて、ソースコードを大量にコミットしてしまうケースがしばしばあります。
何らか禁止する手段はありますでしょうか？

回答No.1

korokokokoro · ベストアンサー

http://park1.wakwak.com/~ima/windows_subversion0001.html

お礼

ご回答ありがとうございます。URLの、
ユーザーに個別に書き込み・読み込み権限を与える設定箇所を見よということでしょうか？
プログラマでない方もソースコードの修正を行って、コミットは行いますので、
読み込み専用の権限設定は出来ません。
単に、「importコマンドの実行のみ禁止したい」というのが趣旨です。
フック等が使えないかどうかと思っておりますが。。

回答No.5

kmee

その「プログラマで無い人」が、修正する機会はどれくらいあるんでしょうか?

頻繁にあるなら、正しい使い方の教育しかないでしょう。

頻度が少ないなら
・ユーザーで管理し、「プログラマ」は読み書き、「そうでない人」は読み取り専用
・「そうでない人」がコミットしたい場合は、「プログラマ」に依頼する(変更箇所をメールやTracで指示する、等)
がいいように思います。

お礼

いつもC/C++の掲示板でのご回答を感心しながら拝見しております。
プログラマでない方の更新頻度・更新範囲は、プログラマ顔負けですので、正しい使い方を誤操作時に確認していただくことにします。

メールで代理コミットを行った時期もあったのですが、そうすると、Tracの代理記入も依頼されて、内容の確認まで行っていたら、私の仕事の手が回らなくなってしまいました。
また、メールでのやり取りの間にソースがデグレていたり、競合が発生したりで、それこそソースコード管理システムを使わないと、整合が取れないという本末転倒な状態に陥りましたので、直接作業をしてもらっています。
ご回答ありがとうございました。

回答No.4

Wr5

>単に、「importコマンドの実行のみ禁止したい」というのが趣旨です。
>フック等が使えないかどうかと思っておりますが。。

Subversionにそういうフックはなさそうですけど…
# コミット、ロック、アンロック、属性変更のフックスクリプトはテンプレートがありますね。

クライアントはなんなのでしょう？
TortoiseSVNならメニューの表示を抑制する方法ならありますけど。
http://tortoisesvn.net/docs/release/TortoiseSVN_ja/tsvn-admins-disablemenus.html
# CUI版svnコマンドのインストールも行っている場合は、svnコマンドでやれちゃいますけどね……。

># Update、Checkoutではなく、ここで間違えてImportを選択する
>(本人曰く、最新の変更を自分のローカルにImportするんじゃないの？)

使い方自体を間違えている(少なくともSVNの使い方とは違う)ので、正しい使い方を覚えて貰う。
ということになるでしょう。
#3で指摘されていますが。
VSS使いだと用語の意味が異なっている場合があった……かと思いますが、ちょっとソースが見つけられない………。

後から追加されるメンバーもいるかも知れませんので、使い方のドキュメントを作成して共有しておいた方がいいかと思いますけど。
その際にチーム内でのローカル的なルールなども記入しておくといいでしょう。
# コミットログの書式とかそういった類のものとか。

お礼

ご回答ありがとうございます。TortoiseSVNの件は、非常に参考になりました。
概念・用語の説明・リポジトリの情報等が書かれたドキュメントは作成しています。
Tracと連携して、チケット駆動で開発をしているので、コミットログの書式も決まっています。

クライアントは様々です。Mac/Linux/Windowsと開発のプラットフォームも様々です。
マルチプラットフォームで動作するソフトウェアなので、定期的にソースをサーバから取得してテストするような仕組みとしています。

ImportはAddを纏めて行うためのコマンドと思うと、フックで制限をかけるのは難しそうですね。ある程度の数以上のファイルをまとめてコミットしようとしたら、エラーにするぐらいでしょうか。
やはり、「よく確認する」を徹底してもらうしかなさそうですね。
間違える頻度からして、修復する方が、教育コストよりも安くつきそうですが、周知徹底したいと思います。

回答No.3

korokokokoro

それって制限云々の問題以前に利用に関してしっかり教育しろよってレベルだろ。
まともに使えないならそのユーザに利用権限与えること自体がおかしい。

やっぱり自分が#1で書いたコミットに対して制限かけてリポジトリが汚れるのを防いだ方がいい。

お礼

頻度としては頻繁ではありません。年に１回起こるかどうかぐらいです。
利用権限を与える方が良いから、そうしているのであって、そこは論点にしておりません。
教習所で教えこんだからといって、事故は０になりませんが、車の利便性は享受したいわけです。
ユーザも、失敗して申し訳ない思いはしていますし、管理側としては、偶発的に起こる操作ミスを防ぎたい、そういう質問です。
情報リテラシの高いプログラマとばかり仕事をできれば良いですが、研究者やデザイナなど、優れたコードを書けるけれども、ツールの使い方が完璧ではないというケースです。
ただ、ほとんど間違えないという前提です。この点を記載しておりませんでした。すみません。
間違えたら、１つ前のリビジョンに戻せば、それで良いといえば、それまでなのですが。
ご回答ありがとうございました。

回答No.2

korokokokoro

>「Checkout」と「Import」の意味を間違えて、ソースコードを大量にコミットしてしまうケースがしばしばあります。
なんでチェックアウトとインポートの意味を間違えてコミット?

お礼

1.ローカルに既にある環境を最新にしようとする
# この環境に自分独自のディレクトリを作成している
# Update、Checkoutではなく、ここで間違えてImportを選択する
(本人曰く、最新の変更を自分のローカルにImportするんじゃないの？)
2.ローカルの自分の修正をサーバーにCommitする
#１で追加されたもの＋自分の修正がアップされる。
の流れです。