タグ

svnに関するiR3のブックマーク (20)

  • Subversionが別のリポジトリにコミットしてしまう

    ここでは、「Subversionが別のリポジトリにコミットしてしまう」 に関する記事を紹介しています。 ■現象 NetBeansにAプロジェクトとBプロジェクトが2つある状態で、 Bプロジェクトの一部のフォルダとファイルをコミットすると、 Aプロジェクトのリポジトリにコミットしてしまって困った。 ■原因 Aプロジェクトから一部のフォルダをコピーして持ってきたときに、 Subversionが管理しているファイルが入っている「.svn」フォルダも 一緒にコピーしてしまったため。 ■対応 Bプロジェクトの間違った参照をしている「.svn」フォルダを削除する。 Bプロジェクトのリポジトリには、そのフォルダは存在しない 扱いに戻るので、AddしてCommitすればOK。 ※.svnフォルダ内のall-wcpropsファイルや、entriesファイルに間違った 参照先のアドレスが入ってます。

    iR3
    iR3 2014/09/25
  • svn merge

    iR3
    iR3 2014/09/02
  • http://www.asahi-net.or.jp/~iu9m-tcym/svndoc/svn_cherry_picking.html

    iR3
    iR3 2014/09/02
    ふむふむ
  • 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 を利用します。この

    iR3
    iR3 2014/09/02
  • (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 merge) 複数のリビジョンを指定してマージ - おはようバッファロー
    iR3
    iR3 2014/09/02
  • svn resolve

    説明作業コピーのファイルやディレクトリの「競合」状態を解決します。この処理は競合マーカを意味的に解決するわけではありませんが、--accept 引数で指定したバージョンで、PATH を置き換え、競合に関係する中間ファイルを削除します。これにより PATH をもう一度コミットできるようにします。つまり、その競合は既に「解決された」と Subversion に伝えます。あなたが希望する解決法により、--accept コマンドに以下の引数を渡せます。 base作業コピーを更新する前の、BASE リビジョンのファイルを選択します。これは、最後の編集を行う前のチェックアウトしたファイルです。working手動で競合解決を行ったと仮定し、現在作業コピーにあるファイルを、このファイルのバージョンとして選択します。mine-full競合したすべてのファイルを、svn update を実行する直前にあったフ

    iR3
    iR3 2014/09/02
  • 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で local delete, incoming edit upon update - メモメモ^^
    iR3
    iR3 2014/09/02
    ふむふむ
  • svn status

    説明作業コピーにあるファイルやディレクトリの状態を表示します。引数がない場合、ローカルで修正されたアイテムだけが表示されます (リポジトリに対するアクセスは発生しません)。--show-updates を使うと、作業リビジョンと、 サーバの最新ではない情報も追加します。--verbose を使うと、すべての項目に対する完全なリビジョン情報を表示します。出力の最初の 6 桁は、それぞれ一文字幅で、各列に作業コピーの項目ごとに、様々な情報を表示します。1 列目は、項目が追加、削除、変更の、どの状態かをを示します。 ' '変更はありません。'A'項目は追加準備されています。'D'項目は削除準備されています。'M'項目は修正されました。'R'項目は作業コピー内で置き換えられました。これは、そのファイルが削除準備され、その場所に同名の新しいファイルが、追加準備されたことを表しています。'C'項目の内

    iR3
    iR3 2014/08/28
  • svn copy

    iR3
    iR3 2014/08/28
  • Subversion ブランチとタグ - とみぞーノート

    1.ブランチ/タグ 1-1 ブランチ/タグの設定 Subversionはブランチとタグは区別がなく単なるファイルの複製でしかない。どちらもsvn copyによりコピーすればよい(コピー先のディレクトリがブランチ名/タグ名と見なせる)。コピーするとファイルがAddされるので、最後に忘れずcommitをすること。 ブランチとタグを区別するためにコピー先をディレクトリで分けておくとよい。 以下の例ではtrunkに流のソースがあり、branches以下にブランチ、tags以下にタグを格納するものとする。 SampleProg/ プロジェクトTop +----trunk/ 流のソースを格納 +----tags/ タグを格納する為のディレクトリ +----branches/ ブランチを格納する為のディレクトリ TrunkからdevBranchブランチを作成する # cd (作業ディレクトリ) #

    iR3
    iR3 2014/08/27
    「ブランチとタグは区別がなく単なるファイルの複製でしかない。どちらもsvn copyによりコピーすればよい(コピー先のディレクトリがブランチ名/タグ名と見なせる)。コピーするとファイルがAddされる」
  • ブランチ・タグ付け

    ランチやタグにコピーしたい作業コピーのフォルダを選択してから、TortoiseSVN → 分岐/タグ... コマンドを選択してください。新しいブランチのデフォルトの先 URL は、作業コピーの基準になった元 URL になっています。ブランチ・タグの新しいパスに URL を編集する必要があるでしょう。つまり、 http://svn.collab.net/repos/ProjectName/trunk の代わりに、 http://svn.collab.net/repos/ProjectName/tags/Release_1.10 のようにするということです。前回使用した命名規則を思い出せなければ、既存のリポジトリ構造を見るのに、リポジトリブラウザを開く右のボタンを押してください。では、コピー元を選択してください、ここでは 3 種類の選択肢があります。 リポジトリの最新 (HEAD) リビジョ

    iR3
    iR3 2014/08/27
    “チープコピーは、Unix のハードリンクと似ています。つまりリポジトリの完全なコピーを作成する代わりに、指定したツリーやリビジョンを指す内部リンクを作成します。”
  • 構成管理 実践入門 第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

    「Subversion実践入門」を読み終えて(ASUB会まとめ) - 旧toyoshiの日記
    iR3
    iR3 2014/06/27
    ふむふむ 13回読むとすっきりするのかぁ
  • 基本的な作業サイクル

    チームを作って作業してるプロジェクトでは、前回更新後にプロジェクトの他のメンバーが加えた変更を受け取るため、作業コピーを更新したくなります。svn update を使って自分の作業コピーを、リポジトリの最新バージョンに同期させてください。$ svn update U foo.c U bar.c リビジョン 2 に更新しました。 この場合、あなたが最後に更新してから、誰か別の人が foo.c と bar.c の両方に加えた変更をコミットしており、Subversion は、この変更をあなたの作業コピーに加えるため更新しました。サーバに svn update で作業コピーに変更を送信する際、作業コピーを最新にするために Subversion が行った処理の内容を、各項目の前に 1 文字で表します。その文字の意味については、svn update をご覧ください。 さて、これで作業ができ、自分の作業

    iR3
    iR3 2014/06/26
    svn status -v -u 覚えた! 覚えることいっぱ〜い
  • 猿にもわかる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。 ┃ ┗

    iR3
    iR3 2014/06/03
  • Subversion の動作

    iR3
    iR3 2014/06/03
  • バージョン管理システム 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

    バージョン管理システム Subversion にバージョン1.8 登場 ― なぜ Git ではなく、SVN を使うのか? - インターネットコム
    iR3
    iR3 2014/05/01
    svnのその点は確かに “「SVN では 1TB のリポジトリを持つことができ、その中の一部分だけをチェックアウトできる。開発者は、すべてのコピーを持つ必要はない。」”
  • 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 の使い方メモ
    iR3
    iR3 2013/12/27
    GJ!
  • layer8.sh

    This domain may be for sale!

    iR3
    iR3 2013/07/18
  • 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

    git-svnでsvnリポジトリの変更を自動で取得する - アジャイルSEを目指すブログ
  • 1