ここでは、「Subversionが別のリポジトリにコミットしてしまう」 に関する記事を紹介しています。 ■現象 NetBeansにＡプロジェクトとＢプロジェクトが２つある状態で、 Ｂプロジェクトの一部のフォルダとファイルをコミットすると、 Ａプロジェクトのリポジトリにコミットしてしまって困った。 ■原因 Ａプロジェクトから一部のフォルダをコピーして持ってきたときに、 Subversionが管理しているファイルが入っている「.svn」フォルダも 一緒にコピーしてしまったため。 ■対応 Ｂプロジェクトの間違った参照をしている「.svn」フォルダを削除する。 Ｂプロジェクトのリポジトリには、そのフォルダは存在しない 扱いに戻るので、AddしてCommitすればＯＫ。 ※.svnフォルダ内のall-wcpropsファイルや、entriesファイルに間違った 参照先のアドレスが入ってます。
svnに関するiR3のブックマーク (20)
-
iR3 2014/09/25
-
-
-
svn merge
書式svn merge [-c M | -r N:M] SOURCE[@REV] [WCPATH]svn merge sourceURL1[@N] sourceURL2[@M] [WCPATH]svn merge sourceWCPATH1@N sourceWCPATH2@M [WCPATH] 説明最初の形式と二番目の形式ではソースとなるパス (最初の形式ではURL、二番目の形式では作業コピーパス) はリビジョン N と M で指定され、この二つを比較します。リビジョンを省略すると HEAD をデフォルトとします。「-c M」 オプションは、N = M-1 の状態の 「-r N:M」 と等価です。「-c -M」 は逆 (N = M-1 の状態の 「-r M:N」) になります。三番目の形式では SOURCE は URL か作業コピーの項目で、その場合、対応した URL を利用します。この
-
(SVN merge) 複数のリビジョンを指定してマージ - おはようバッファロー
[svn merge] 複数のリビジョンを指定してマージする方法 会社の人から教えてもらった方法 ・1500と1501の間でおきた変更分をマージする場合 svn merge -r1500:1501 http://svn.hoge.com/trunk . ・1500と1505と1509でおきた変更分をマージする場合 svn merge -c 1500,1505,1509 http://svn.hoge.com/trunk .リビジョンを跨ぎたくない場合は、"-c"が便利かと思います。
-
svn resolve
説明作業コピーのファイルやディレクトリの「競合」状態を解決します。この処理は競合マーカを意味的に解決するわけではありませんが、--accept 引数で指定したバージョンで、PATH を置き換え、競合に関係する中間ファイルを削除します。これにより PATH をもう一度コミットできるようにします。つまり、その競合は既に「解決された」と Subversion に伝えます。あなたが希望する解決法により、--accept コマンドに以下の引数を渡せます。 base作業コピーを更新する前の、BASE リビジョンのファイルを選択します。これは、最後の編集を行う前のチェックアウトしたファイルです。working手動で競合解決を行ったと仮定し、現在作業コピーにあるファイルを、このファイルのバージョンとして選択します。mine-full競合したすべてのファイルを、svn update を実行する直前にあったフ
-
svnで local delete, incoming edit upon update - メモメモ＾＾
$ svn st ! C ********** > local delete, incoming edit upon update こんな感じになった。で、検索すると 「svn resolve --accept=working share」と、打てばいいとあるけど、 私は解消しなかった。で、もうちと他の方法を調べると svn: how to resolve “local edit, incoming delete upon update” message $ svn st ! + C foo > local edit, incoming delete upon update ! + C bar > local edit, incoming delete upon update $ touch foo bar $ svn revert foo bar $ rm foo bar とある。自分の
-
svn status
説明作業コピーにあるファイルやディレクトリの状態を表示します。引数がない場合、ローカルで修正されたアイテムだけが表示されます (リポジトリに対するアクセスは発生しません)。--show-updates を使うと、作業リビジョンと、 サーバの最新ではない情報も追加します。--verbose を使うと、すべての項目に対する完全なリビジョン情報を表示します。出力の最初の 6 桁は、それぞれ一文字幅で、各列に作業コピーの項目ごとに、様々な情報を表示します。1 列目は、項目が追加、削除、変更の、どの状態かをを示します。 ' '変更はありません。'A'項目は追加準備されています。'D'項目は削除準備されています。'M'項目は修正されました。'R'項目は作業コピー内で置き換えられました。これは、そのファイルが削除準備され、その場所に同名の新しいファイルが、追加準備されたことを表しています。'C'項目の内
-
-
Subversion ブランチとタグ - とみぞーノート
1.ブランチ/タグ 1-1 ブランチ/タグの設定 Subversionはブランチとタグは区別がなく単なるファイルの複製でしかない。どちらもsvn copyによりコピーすればよい(コピー先のディレクトリがブランチ名/タグ名と見なせる)。コピーするとファイルがAddされるので、最後に忘れずcommitをすること。 ブランチとタグを区別するためにコピー先をディレクトリで分けておくとよい。 以下の例ではtrunkに本流のソースがあり、branches以下にブランチ、tags以下にタグを格納するものとする。 SampleProg/ プロジェクトTop +----trunk/ 本流のソースを格納 +----tags/ タグを格納する為のディレクトリ +----branches/ ブランチを格納する為のディレクトリ TrunkからdevBranchブランチを作成する # cd (作業ディレクトリ) #
-
ブランチ・タグ付け
ブランチやタグにコピーしたい作業コピーのフォルダを選択してから、TortoiseSVN → 分岐/タグ... コマンドを選択してください。新しいブランチのデフォルトの先 URL は、作業コピーの基準になった元 URL になっています。ブランチ・タグの新しいパスに URL を編集する必要があるでしょう。つまり、 http://svn.collab.net/repos/ProjectName/trunk の代わりに、 http://svn.collab.net/repos/ProjectName/tags/Release_1.10 のようにするということです。前回使用した命名規則を思い出せなければ、既存のリポジトリ構造を見るのに、リポジトリブラウザを開く右のボタンを押してください。では、コピー元を選択してください、ここでは 3 種類の選択肢があります。 リポジトリの最新 (HEAD) リビジョ
-
構成管理 実践入門 第2章 Subversionによるバージョン管理入門 チーム開発に関連する操作
ここからは、作業コピーAと作業コピーBを題材に、Subversionのチーム開発に関連する操作を見ていきます。 まず準備として、通常の並行開発に見立てて、作業コピーBのほうにも変更を加えておきましょう。 作業コピーBのhoge.txt、hoge_conflict.txtを以下のように変更してください。 【hoge.txt】 a B C 【hoge_conflict.txt】 a B E 更新 先ほど作業コピーAでコミットした内容は、まだ作業コピーBには反映されていません。リポジトリの最新状態と同期を取るために「更新」（アップデート）と呼ばれる作業が必要になります。 更新を行う作業コピーのディレクトリ（C:\work\2\B）に移動し、svn updateコマンドでリポジトリと同期化を行います。 ●【更新】 svn update C:\ work\ 2\ B> svn update D ho
-
「Subversion実践入門」を読み終えて（ASUB会まとめ） - 旧toyoshiの日記
4月11日ごろからid:taje4120と毎朝少しずつSubversion実践入門という本を読んだ。 朝にサブバージョンを勉強する会だからASUB会と名前をつけた。 その勉強会も終わり、1週間ほどたったので復習をかねて内容をまとめる。 「Subversion実践入門」を読んで得られたこと 本書を読む前によくわかっていなかったことをベースにふりかえる いまcommitしたら何がcommitできるか知りたい svn status [file_name] いまupdateしたら何がupdateされるのか知りたい svn status --show-updates #-uだけでもOK trunk branches tagsの使い分け プロジェクトのリポジトリは以下のようにツリーを分けるのが慣習になっている 開発のメインラインとしてのトランク(trunk) 完成したコードをまとめるブランチ(bran
-
基本的な作業サイクル
チームを作って作業してるプロジェクトでは、前回更新後にプロジェクトの他のメンバーが加えた変更を受け取るため、作業コピーを更新したくなります。svn update を使って自分の作業コピーを、リポジトリの最新バージョンに同期させてください。$ svn update U foo.c U bar.c リビジョン 2 に更新しました。 この場合、あなたが最後に更新してから、誰か別の人が foo.c と bar.c の両方に加えた変更をコミットしており、Subversion は、この変更をあなたの作業コピーに加えるため更新しました。サーバに svn update で作業コピーに変更を送信する際、作業コピーを最新にするために Subversion が行った処理の内容を、各項目の前に 1 文字で表します。その文字の意味については、svn update をご覧ください。 さて、これで作業ができ、自分の作業
-
猿にもわかるsvn入門
はじめに repo='http://svn.momonga-linux.org/svn/pkgs' という shell 変数が定義されているものとして話を進めます. 割と頻繁に URI を打つ事があるので短かめの変数を定義しておくことを お勧めします. Q. 今のsvn repoって結局どうなのよ？ A. 以下のようになっています。(2006-08/15現在) 詳しくはここらへん参照 http://developer.momonga-linux.org/viewvc/ http://developer.momonga-linux.org/viewvc/branches/ 使う事が少ないtags以下は省略しています。 http://svn.momonga-linux.org/svn/pkgs / ┣ trunk/ ┃ ┣ pkgs/ 最先端のパッケージ。通常はこちらを使用すればok。 ┃ ┗
-
-
バージョン管理システム Subversion にバージョン1.8 登場 ― なぜ Git ではなく、SVN を使うのか？ - インターネットコム
オープンソースのバージョンコントロールシステム Apache Subversion（SVN）1.8 が6月18日リリースされた。この最新版は、およそ20か月前にリリースされた SVN 1.7 の後継バージョンであり、開発者に対して多くの新機能を提供するものだ。 SVN 1.8 はまた、「なぜ Git ではなく、SVN を使うのか？」という疑問への回答を与えてくれるリリースとなっている。 WC-NG 前バージョン SVN 1.7 の最大の目玉は、WC-NG（working copy next generation）の導入だった。WC-NG は、SVN 1.8 および今後のリリースで提供される新機能のベースとなっている。Apache Software Foundation の元議長であり、Apache Subversion プロジェクトの VP である Greg Stein 氏は、Int
-
git-svn の使い方メモ
git-svn.markdown git-svn の使い方メモ git-svn の使い方をメモする。他によいプラクティスがあれば指摘していただけるとありがたい。 用語 SVN のブランチと git のブランチが混在しているため、ここではブランチという語を以下のように区別する。 ブランチ、 SVN ブランチ：$SVN_REPO/branches 以下にあるディレクトリ ローカルブランチ：git のローカルブランチ リモートブランチ：git のリモートブランチ 例題の SVN リポジトリの構成 このメモでは SVN リポジトリが以下のような構造になっているとする。 $SVN_REPO/ foo/ bar/ branches/ foo-x/ foo-y/ bar-new-feature/ このリポジトリは標準レイアウトではない（trunk/ や tags/ がない）。トップレベルのディレクトリが
-
-
git-svnでsvnリポジトリの変更を自動で取得する - アジャイルSEを目指すブログ
久しぶりにsvnを触ったら、logの表示やupdateがあまりに遅い。 git-svnを使っても、やっぱりupdateは遅い。 という訳で 勝手にgit svn fetchするようにbat/shを書いてみた。 バッチファイル・スクリプト 標準出力で出してる文字は下記の意味にしてる。 - : 待機中 > : git-svnのfetch 処理中 . : git-svnのfetch 終了 auto_svn_update.bat @echo off set LIMIT=600 set SLEEP_EXE="%ProgramFiles(x86)%\Git\bin\sleep.exe" set GIT_EXE="%ProgramFiles(x86)%\Git\bin\git.exe" %GIT_EXE% svn fetch :LOOP set /p x="-" < nul %SLEEP_EXE% %L
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました