refactor(import-svn):

Author: YasinDehfuli

book/09-git-and-other-scms/sections/import-svn.asc

@@ -1,65 +1,42 @@
-==== ساب‌ورژن
+==== Subversion (ساب‌ورژن)
 
 (((Subversion)))
 (((Importing, from Subversion)))
-اگر بخش قبلی را درباره استفاده از `git svn` خوانده‌اید، می‌توانید به راحتی از آن دستورالعمل‌ها برای
-        `git svn clone` یک مخزن استفاده کنید؛ سپس، استفاده از سرور ساب‌ورژن را متوقف کرده، به یک سرور گیت
-        جدید فشار دهید و شروع به استفاده از آن کنیدارائه داده است.
-        اگر می‌خواهید تاریخچه را داشته باشید، می‌توانید این کار را به سرعت انجام دهید، همانطور که می‌توانید داده‌ها را
-        از سرور ساب‌ورژن خارج کنید (که ممکن است مدتی طول بکشد).
-
-با این حال، واردات کامل نیست؛ و از آنجا که این کار زمان زیادی می‌برد، بهتر است آن را به درستی انجام دهید.
-        اولین مشکل اطلاعات نویسنده است.
-        در ساب‌ورژن، هر شخصی که کامیت می‌کند، یک کاربر در سیستم دارد که در اطلاعات کامیت ثبت می‌شود.
-        مثال‌های بخش قبلی نشان می‌دهند که `schacon` در برخی مکان‌ها، مانند خروجی `blame` و `git
-          svn log` وجود دارد.
-        اگر می‌خواهید این را به داده‌های نویسنده بهتری در گیت نگاشت کنید، به یک نگاشت از کاربران ساب‌ورژن به نویسندگان
-        گیت نیاز دارید.
-        یک فایل به نام `users.txt` ایجاد کنید که این نگاشت را به فرمت زیر داشته باشد:
+
+اگر بخش قبلی در مورد استفاده از `git svn` را خوانده باشید، می‌توانید به راحتی از آن دستورالعمل‌ها برای `git svn clone` یک مخزن استفاده کنید؛ سپس از استفاده از سرور Subversion دست بردارید، به سرور جدید Git منتقل کنید و شروع به استفاده از آن کنید. اگر می‌خواهید تاریخچه را نیز حفظ کنید، می‌توانید به سرعت این کار را انجام دهید، به شرطی که داده‌ها را از سرور Subversion استخراج کنید (که ممکن است کمی زمان ببرد).
+
+با این حال، واردات کامل نیست؛ و چون این فرآیند طولانی خواهد بود، بهتر است آن را به درستی انجام دهید. اولین مشکل اطلاعات نویسنده است. در Subversion، هر شخصی که commit می‌کند، یک کاربر در سیستم دارد که در اطلاعات commit ثبت می‌شود. نمونه‌های بخش قبلی schacon را در برخی مکان‌ها نشان می‌دهند، مانند خروجی blame و git svn log. اگر می‌خواهید این را به داده‌های نویسنده بهتری در Git نگاشت کنید، به یک نگاشت از کاربران Subversion به نویسندگان Git نیاز دارید. یک فایل به نام users.txt ایجاد کنید که این نگاشت را در فرمت زیر داشته باشد:
+
 
 [source]
 ----
 schacon = Scott Chacon <[email protected]>
 selse = Someo Nelse <[email protected]>
 ----
 
-برای دریافت لیستی از نام‌های نویسنده‌ای که SVN استفاده می‌کند، می‌توانید این دستور را اجرا کنید:
+برای دریافت فهرستی از نام‌های نویسندگان که SVN استفاده می‌کند، می‌توانید دستور زیر را اجرا کنید:
 
 [source,console]
 ----
 $ svn log --xml --quiet | grep author | sort -u | \
   perl -pe 's/.*>(.*?)<.*/$1 = /'
 ----
 
-این خروجی لاگ را به فرمت XML تولید می‌کند، سپس فقط خطوطی که اطلاعات نویسنده را دارند نگه می‌دارد، تکراری‌ها را
-        حذف می‌کند و تگ‌های XML را حذف می‌کند.
-        بدیهی است که این فقط بر روی سیستمی که `grep`، `sort` و `perl` نصب شده کار
-        می‌کند.
-        سپس، آن خروجی را به فایل `users.txt` خود هدایت کنید تا بتوانید داده‌های معادل کاربر گیت را در کنار هر
-        ورودی اضافه کنید.
+این دستور خروجی لاگ را در فرمت XML تولید می‌کند، سپس فقط خطوطی که اطلاعات نویسنده را دارند نگه می‌دارد، تکراری‌ها را حذف می‌کند و برچسب‌های XML را حذف می‌کند. مشخصاً این تنها روی سیستمی که `grep`، `sort` و `perl` نصب شده باشد کار می‌کند. سپس آن خروجی را به فایل `users.txt` هدایت کنید تا بتوانید داده‌های معادل نویسنده Git را در کنار هر ورودی اضافه کنید.
 
 [NOTE]
 ====
-اگر این کار را بر روی یک ماشین ویندوزی انجام می‌دهید، اینجا جایی است که با مشکل مواجه خواهید شد.
-                مایکروسافت برخی نکات و نمونه‌های خوب را در https://docs.microsoft.com/en-us/azure/devops/repos/git/perform-migration-from-svn-to-git[].
+اگر این کار را روی یک سیستم ویندوزی امتحان می‌کنید، این نقطه‌ای است که ممکن است با مشکل مواجه شوید. مایکروسافت مشاوره‌ها و نمونه‌های خوبی را در آدرس https://docs.microsoft.com/en-us/azure/devops/repos/git/perform-migration-from-svn-to-git[] ارائه داده است.
 ====
 
-شما می‌توانید این فایل را به `git svn` ارائه دهید تا به آن کمک کند داده‌های نویسنده را به طور
-        دقیق‌تری نگاشت کند.
-        همچنین می‌توانید به `git svn` بگویید که متاداده‌ای که ساب‌ورژن معمولاً وارد می‌کند را شامل نشود، با
-        عبور از `--no-metadata` به دستور `clone` یا `init`.
-        متاداده شامل یک `git-svn-id` در هر پیام کامیت است که گیت در حین واردات تولید می‌کند.
-        این می‌تواند لاگ گیت شما را بزرگ کند و ممکن است کمی نامشخص باشد.
+شما می‌توانید این فایل را به دستور `git svn` ارائه دهید تا به آن کمک کند اطلاعات نویسنده را دقیق‌تر نگاشت کند. همچنین می‌توانید به `git svn` بگویید که متاداده‌هایی که معمولاً توسط Subversion وارد می‌شود را شامل نکند، با استفاده از فلگ `--no-metadata` در دستور `clone` یا `init`. متاداده شامل یک `git-svn-id` در داخل هر پیغام commit است که Git در حین واردات تولید می‌کند. این می‌تواند لاگ Git شما را بزرگ کرده و ممکن است آن را کمی غیرقابل فهم کند.
 
 [NOTE]
 ====
-شما باید متاداده را نگه دارید زمانی که می‌خواهید کامیت‌های انجام شده در مخزن گیت را به مخزن اصلی
-                ساب‌ورژن برگردانید.
-                اگر نمی‌خواهید همگام‌سازی در لاگ کامیت شما باشد، می‌توانید پارامتر `--no-metadata` را حذف
-                کنید.
+شما نیاز به نگهداری متاداده زمانی دارید که بخواهید commitهای انجام شده در مخزن Git را دوباره به مخزن اصلی SVN منتقل کنید. اگر نمی‌خواهید همگام‌سازی در لاگ commit شما ظاهر شود، می‌توانید از پارامتر `--no-metadata` صرف‌نظر کنید.
 ====
 
-این دستور `import` شما را به شکل زیر می‌کند:
+این دستور باعث می‌شود که دستور `import` شما به شکل زیر باشد:
 
 [source,console]
 ----
@@ -68,13 +45,12 @@ $ git svn clone http://my-project.googlecode.com/svn/ \
 $ cd my_project
 ----
 
-اکنون باید یک واردات ساب‌ورژن زیباتر در دایرکتوری `my_project` خود داشته باشید.
-        به جای کامیت‌هایی که به این شکل به نظر می‌رسند
+حالا باید یک واردات بهتر از Subversion در دایرکتوری `my_project` خود داشته باشید. به جای commitهایی که به این شکل هستند
 
 [source]
 ----
 commit 37efa680e8473b615de980fa935944215428a35a
-Author: schacon <schacon@>
+Author: schacon <schacon@4c93b258-373f-11de-be05-5f7a86268029>
 Date:   Sun May 3 00:12:22 2009 +0000
 
     fixed install - go to trunk
@@ -83,7 +59,7 @@ Date:   Sun May 3 00:12:22 2009 +0000
     be05-5f7a86268029
 ----
 
-آن‌ها به این شکل به نظر می‌رسند:
+آنها به این شکل هستند:
 
 [source]
 ----
@@ -94,68 +70,55 @@ Date:   Sun May 3 00:12:22 2009 +0000
     fixed install - go to trunk
 ----
 
-نه تنها فیلد نویسنده به مراتب بهتر به نظر می‌رسد، بلکه `git-svn-id` نیز دیگر وجود ندارد.
+نه تنها فیلد Author خیلی بهتر به نظر می‌رسد، بلکه `git-svn-id` نیز دیگر وجود ندارد.
 
-شما همچنین باید کمی تمیزکاری پس از واردات انجام دهید.
-        برای یک چیز، باید ارجاعات عجیبی که `git svn` تنظیم کرده است را پاک کنید.
-        اول، برچسب‌ها را به گونه‌ای منتقل کنید که برچسب‌های واقعی باشند نه شاخه‌های دور از نوع عجیب، و سپس بقیه شاخه‌ها
-        را به شاخه‌های محلی منتقل کنید.
+همچنین باید کمی تمیزکاری پس از واردات انجام دهید. اولاً، باید ارجاعات عجیبی که `git svn` ایجاد کرده است را پاک کنید. ابتدا تگ‌ها را جابه‌جا خواهید کرد تا تگ‌های واقعی شوند نه شاخه‌های عجیب از راه دور، سپس باقی‌مانده شاخه‌ها را جابه‌جا خواهید کرد تا به شاخه‌های محلی تبدیل شوند.
 
-برای انتقال برچسب‌ها به برچسب‌های واقعی گیت، این دستور را اجرا کنید:
+برای جابه‌جایی تگ‌ها به تگ‌های مناسب Git، دستور زیر را اجرا کنید:
 
 [source,console]
 ----
 $ for t in $(git for-each-ref --format='%(refname:short)' refs/remotes/tags); do git tag ${t/tags\//} $t && git branch -D -r $t; done
 ----
 
-این ارجاعات را که شاخه‌های دور بودند و با `refs/remotes/tags/` شروع می‌شدند، به برچسب‌های واقعی
-        (سبک) تبدیل می‌کند.
+این دستور ارجاعات مربوط به شاخه‌های از راه دور که با `refs/remotes/tags/` شروع می‌شدند را گرفته و آن‌ها را به تگ‌های واقعی (سبک‌وزن) تبدیل می‌کند.
 
-سپس، بقیه ارجاعات زیر `refs/remotes` را به شاخه‌های محلی منتقل کنید:
+سپس، باقی‌مانده ارجاعات زیر `refs/remotes` را به شاخه‌های محلی تبدیل کنید:
 
 [source,console]
 ----
 $ for b in $(git for-each-ref --format='%(refname:short)' refs/remotes); do git branch $b refs/remotes/$b && git branch -D -r $b; done
 ----
 
-ممکن است ببینید که برخی از شاخه‌های اضافی وجود دارند که با `@xxx` (که xxx یک عدد است) ختم می‌شوند،
-        در حالی که در ساب‌ورژن فقط یک شاخه می‌بینید.
-        این واقعاً یک ویژگی ساب‌ورژن به نام "peg-revisions" است که چیزی است که گیت به سادگی معادل نحوی ندارد.
-        بنابراین، `git svn` به سادگی شماره نسخه svn را به نام شاخه اضافه می‌کند، درست به همان روشی که شما در
-        svn می‌نویسید تا به peg-revision آن شاخه اشاره کنید.
-        اگر دیگر به peg-revisions اهمیتی نمی‌دهید، به سادگی آن‌ها را حذف کنید:
+ممکن است با برخی شاخه‌های اضافی روبه‌رو شوید که با `@xxx` (که در آن xxx یک عدد است) پسوند خورده‌اند، در حالی که در Subversion فقط یک شاخه مشاهده می‌کنید. این در واقع یک ویژگی از Subversion به نام `peg-revisions` است، که چیزی است که Git هیچ معادل نحوی برای آن ندارد. بنابراین، `git svn` به سادگی شماره نسخه svn را به نام شاخه اضافه می‌کند، به همان روشی که شما در svn برای ارجاع به peg-revision آن شاخه نوشته‌اید. اگر دیگر به peg-revisions اهمیتی نمی‌دهید، به سادگی آن‌ها را حذف کنید:
 
 [source,console]
 ----
 $ for p in $(git for-each-ref --format='%(refname:short)' | grep @); do git branch -D $p; done
 ----
 
-اکنون تمام شاخه‌های قدیمی، شاخه‌های واقعی گیت هستند و تمام برچسب‌های قدیمی، برچسب‌های واقعی گیت هستند.
+حال همه شاخه‌های قدیمی به شاخه‌های واقعی Git تبدیل شده‌اند و تمام تگ‌های قدیمی به تگ‌های واقعی Git تبدیل شده‌اند.
 
-یک چیز آخر برای تمیز کردن وجود دارد.
-        متأسفانه، `git svn` یک شاخه اضافی به نام `trunk` ایجاد می‌کند که به شاخه پیش‌فرض ساب‌ورژن
-        اشاره دارد، اما ارجاع `trunk` به همان مکان `master` اشاره می‌کند.
-        از آنجا که `master` به طور ایدئولوژیک گیت است، اینجا چگونگی حذف شاخه اضافی است:
+یک چیز آخر برای تمیزکاری باقی‌مانده است. متاسفانه، `git svn` یک شاخه اضافی به نام `trunk` ایجاد می‌کند که به شاخه پیش‌فرض Subversion اشاره دارد، اما ارجاع trunk به همان مکانی اشاره می‌کند که `master` است. از آنجا که `master` به طور معمول در Git استفاده می‌شود، اینجا نحوه حذف شاخه اضافی آورده شده است:
 
 [source,console]
 ----
 $ git branch -d trunk
 ----
 
-آخرین کاری که باید انجام دهید این است که سرور گیت جدید خود را به عنوان یک ریموت اضافه کنید و به آن فشار دهید.
-        در اینجا یک مثال از افزودن سرور خود به عنوان یک ریموت است:
+آخرین کاری که باید انجام دهید، اضافه کردن سرور جدید Git خود به عنوان یک remote و سپس push کردن به آن است. در اینجا یک مثال از اضافه کردن سرور خود به عنوان یک remote آورده شده است:
 
 [source,console]
 ----
 $ git remote add origin git@my-git-server:myrepository.git
 ----
 
-زیرا می‌خواهید تمام شاخه‌ها و برچسب‌های خود را بالا ببرید، اکنون می‌توانید این را اجرا کنید:
+چون می‌خواهید تمام شاخه‌ها و تگ‌های خود را ارسال کنید، اکنون می‌توانید دستور زیر را اجرا کنید:
 
 [source,console]
 ----
 $ git push origin --all
 $ git push origin --tags
 ----
 
-تمام شاخه‌ها و برچسب‌های شما باید در سرور گیت جدید شما در یک واردات زیبا و تمیز باشد.
+تمام شاخه‌ها و تگ‌های شما باید در سرور جدید Git شما در یک واردات تمیز و مرتب قرار داشته باشند.