Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pl.comp.programming > #34563 > unrolled thread
| Started by | Robert Magdziarz <robert.magdziarz.1972@gmail.com> |
|---|---|
| First post | 2021-08-23 05:59 -0700 |
| Last post | 2021-10-17 18:35 +0200 |
| Articles | 20 on this page of 162 — 10 participants |
Back to article view | Back to pl.comp.programming
rzadki bład w programie w C++ Robert Magdziarz <robert.magdziarz.1972@gmail.com> - 2021-08-23 05:59 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-23 06:44 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <robert.magdziarz.1972@gmail.com> - 2021-08-23 07:04 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-23 07:48 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <robert.magdziarz.1972@gmail.com> - 2021-08-23 11:57 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-24 01:12 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <robert.magdziarz.1972@gmail.com> - 2021-08-24 01:57 -0700
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-24 11:19 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-24 07:39 -0700
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-24 17:27 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-24 08:50 -0700
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-24 19:41 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-24 21:40 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-25 09:53 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-25 10:02 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-25 10:34 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-25 11:03 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-25 11:21 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-25 02:20 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-25 11:31 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-25 11:55 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-25 03:09 -0700
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-25 14:44 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-25 06:39 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-25 16:18 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-25 16:36 +0200
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-08-24 11:58 -0700
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-25 09:22 +0200
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-08-25 13:31 -0700
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-26 09:40 +0200
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-08-28 13:10 -0700
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-30 09:54 +0200
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-08-30 12:10 -0700
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-30 21:31 +0200
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-08-31 11:01 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 21:42 +0200
Re: rzadki bład w programie w C++ slawek <x.y@org.org> - 2021-10-17 17:27 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-26 09:55 +0200
Re: rzadki bład w programie w C++ slawek <x.y@org.org> - 2021-10-17 17:32 +0200
Re: rzadki bład w programie w C++ kriters <kritersi@o2.pl> - 2021-08-25 23:00 +0200
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-08-28 12:46 -0700
Re: rzadki bład w programie w C++ kriters <kritersi@o2.pl> - 2021-08-28 22:31 +0200
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-08-29 11:39 -0700
Re: rzadki bład w programie w C++ kriters <kritersi@o2.pl> - 2021-08-29 22:12 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-30 09:35 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 09:54 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-30 10:44 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 11:03 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-30 11:51 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 12:29 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-30 13:20 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 13:30 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-30 14:21 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 14:39 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-30 05:53 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 15:04 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-30 06:11 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 15:19 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-30 06:37 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 16:08 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-30 16:33 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 16:39 +0200
Re: rzadki bład w programie w C++ arnold@hooterville.invalid (Arnold Ziffel) - 2021-09-03 14:40 +0000
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-30 14:36 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-31 16:00 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-31 16:05 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-30 14:56 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 15:07 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-30 06:39 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 15:51 +0200
Re: rzadki bład w programie w C++ slawek <x.y@org.org> - 2021-10-17 18:09 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 13:42 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-30 14:50 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 15:11 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-30 16:02 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 16:16 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-30 16:30 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 16:39 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-30 02:11 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 11:29 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-30 02:53 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 12:22 +0200
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-08-30 11:44 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 21:27 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-30 21:38 +0200
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-08-31 11:10 -0700
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-09-01 13:41 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-09-01 05:15 -0700
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-09-01 14:40 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-09-01 06:09 -0700
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-09-01 15:22 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-09-01 07:14 -0700
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-09-01 11:13 -0700
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-09-02 09:30 +0200
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-09-02 11:57 -0700
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-09-03 09:18 +0200
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-09-03 11:21 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-09-03 12:45 -0700
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-09-04 11:07 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-09-04 11:38 -0700
Re: rzadki bład w programie w C++ slawek <x.y@org.org> - 2021-10-17 17:45 +0200
Re: rzadki bład w programie w C++ slawek <x.y@org.org> - 2021-10-17 17:38 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-29 14:23 +0200
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-08-29 11:57 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-29 23:26 +0200
Re: rzadki bład w programie w C++ Mateusz Viste <mateusz@xyz.invalid> - 2021-08-30 09:26 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-30 09:49 +0200
Re: rzadki bład w programie w C++ slawek <x.y@org.org> - 2021-10-17 17:20 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-24 07:33 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-08-25 09:14 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-25 12:22 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-08-25 21:57 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-25 23:59 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-08-26 07:40 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-26 09:36 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-08-26 10:19 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-08-26 10:29 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-26 20:56 +0200
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-08-26 12:32 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-26 21:54 +0200
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-08-26 23:04 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-27 01:31 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-27 14:42 +0200
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-08-27 07:58 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-27 17:11 +0200
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-27 17:13 +0200
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-08-27 08:57 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-27 11:59 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-27 01:17 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-08-27 02:18 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-27 02:44 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-08-27 03:14 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-08-27 03:16 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-08-25 04:53 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-08-25 05:08 -0700
Re: rzadki bład w programie w C++ Zbych <zbych@somewhere.com> - 2021-08-23 16:55 +0200
Re: rzadki bład w programie w C++ Maciej Sobczak <see.my.homepage@gmail.com> - 2021-08-23 11:51 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-08-24 21:05 +0200
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-09-08 08:28 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-09-09 00:57 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-09-09 10:58 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-09-09 12:47 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-09-09 22:56 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-09-10 00:26 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-09-10 00:59 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-09-21 02:59 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-09-21 12:07 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-09-21 08:56 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-09-21 23:19 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-09-21 23:22 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-09-22 09:27 +0200
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-09-22 02:59 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-09-22 12:53 +0200
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-09-22 04:13 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-09-22 07:03 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-09-22 08:35 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-09-22 10:24 -0700
Re: rzadki bład w programie w C++ heby <heby@poczta.onet.pl> - 2021-09-22 19:35 +0200
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-09-22 14:22 -0700
Re: rzadki bład w programie w C++ Robert Magdziarz <rmagdziarz2018@rmagdziarz2018.e-kei.pl> - 2021-09-30 21:24 -0700
Re: rzadki bład w programie w C++ Maciek Godek <godek.maciek@gmail.com> - 2021-10-01 00:52 -0700
Re:rzadki bład w programie w C++ slawek <x.y@org.org> - 2021-10-17 18:35 +0200
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2021-08-25 11:55 +0200 |
| Message-ID | <20210825115525.066bff1f@mateusz.lan> |
| In reply to | #34607 |
2021-08-25 o 02:20 -0700, Maciek Godek napisał: > Ostatni raz korzystałem z SVN w okolicach 2012 roku, i wspominam > robienie branchy i merge'ów jako koszmar. Na świeżej (wówczas) wersji svn? Dziwne. Musiałbyś więcej szczegółów podać, albo powtórzyć doświadczenie i opisać. > git jest lepiej koncepcyjnie pomyślany Do bani z taką koncepcją, że każdy musi mieć na pececie swój własny "niby-serwer" i synchronizować wszystko w obie strony, przy tym chowając swoja zmiany przed światem tak długo, jak się da. No i te setki opcji, przełączników, trybów... > i bardziej skalowalny Nie będę się spierał, bo moje doświadczenie w adminowaniu svn-em jest ograniczone do kilkuosobowych projektów, ale niemniej wypadałoby to stwierdzenie jakoś uargumentować. Przez wiele lat z svn korzystały duże i bardzo duże projekty. Wnioskuję więc, że jednak da się. Jednym z ostatnich "dużych" projektów open-source, który wyemigrował z svn jest FreeBSD. Jeden z core programistów podaje przesłanki za tą zmianą: https://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html W żadnym punkcie nie pada "gorsza skalowalność". Podane argumenty sprowadzają się do dwóch rzeczy: "bo wszyscy tak robią" i "git pozwala ładnie formatować patche, ułatwiając ich przyjmowanie z zewnątrz". > Tak czy siak - jak Sobczak słusznie zauważył - dywagowanie o > wyższości jednego systemu kontroli wersji nad drugim w wątku > dotyczącym problemów w programie C++owym nie ma za dużo sensu. Dyskusja to taki proces, że z czasem może zupełnie zmienić kierunek, w zależności od zainteresowań i woli jej uczestników. > Ja bym każdemu kto jeszcze nie ma swojej preferencji raczej polecał > gita, i to właśnie ze względu na ową "modność" Czyli już nie ze względu na "dług technologiczny", "niebotyczne komplikacje" i rzekomą "prostotę gita"? No ok, moda to też jakiś argument. Niekoniecznie zresztą zły. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Maciek Godek <godek.maciek@gmail.com> |
|---|---|
| Date | 2021-08-25 03:09 -0700 |
| Message-ID | <d859f3cf-2184-4301-ae9c-31b3157956e8n@googlegroups.com> |
| In reply to | #34610 |
środa, 25 sierpnia 2021 o 11:55:26 UTC+2 Mateusz Viste napisał(a): > 2021-08-25 o 02:20 -0700, Maciek Godek napisał: > > Ostatni raz korzystałem z SVN w okolicach 2012 roku, i wspominam > > robienie branchy i merge'ów jako koszmar. > Na świeżej (wówczas) wersji svn? Nie wiem. Pewne dość świeżej bo to stało na w miarę aktualnym Ubuntu. > Dziwne. Musiałbyś więcej szczegółów podać, albo powtórzyć doświadczenie i opisać. Pewnie tak, ale na to raczej nie ma szans :D > > git jest lepiej koncepcyjnie pomyślany > Do bani z taką koncepcją, że każdy musi mieć na pececie swój własny > "niby-serwer" i synchronizować wszystko w obie strony, przy tym > chowając swoja zmiany przed światem tak długo, jak się da. No i te > setki opcji, przełączników, trybów... Główna koncepcja to jest raczej "content-addressable storage". Od strony doświadczenia użytkownika można z tego korzystać dokładnie tak samo, jak z SVNa, jeśli się chce. Co do "chowania wszystkiego przed światem tak długo, jak się da", to nie rozumiem. > > i bardziej skalowalny > > Nie będę się spierał, bo moje doświadczenie w adminowaniu svn-em jest > ograniczone do kilkuosobowych projektów, ale niemniej wypadałoby to > stwierdzenie jakoś uargumentować. Przez wiele lat z svn korzystały duże > i bardzo duże projekty. Wnioskuję więc, że jednak da się. Jednym z > ostatnich "dużych" projektów open-source, który wyemigrował z svn jest > FreeBSD. Jeden z core programistów podaje przesłanki za tą zmianą: > https://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html > > W żadnym punkcie nie pada "gorsza skalowalność". Tutaj jest: "Git can easily and robustly be mirrored. Subversion can be mirrored, but that mirroring is far from robust."
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2021-08-25 14:44 +0200 |
| Message-ID | <20210825144401.0dd4fb0e@mateusz> |
| In reply to | #34611 |
2021-08-25 o 03:09 -0700, Maciek Godek napisał: > Główna koncepcja to jest raczej "content-addressable storage". Nie ma w tym niczego fajnego, to tylko pokłosie decentralizacji. > Od strony doświadczenia użytkownika można z tego korzystać dokładnie > tak samo, jak z SVNa, jeśli się chce. Znaczy patrząc na dwie rewizje mogę rzutem oka stwierdzić, która jest wcześniejsza, i oszacować mniej więcej o ile? No to git. :) > Co do "chowania wszystkiego przed światem tak długo, jak się da", to > nie rozumiem. O lokalne commity chodzi, i o kryjące się za nimi podejście "nie pokażę co robię póki nie wycackam tego do końca". > > W żadnym punkcie nie pada "gorsza skalowalność". > > Tutaj jest: > "Git can easily and robustly be mirrored. Subversion can be mirrored, > but that mirroring is far from robust." Klonowanie repozytoriów svn działa bardzo sprawnie (svnsync), korzystałem z tego wielokrotnie w ramach przeprowadzania repozytoriów svn między serwerami, a także w ramach duplikowania lokalnego repo FreeBSD w domu, kiedy jeszcze miałem w piwnicy kilka instalacji BSD. Ale fakt - nie jest to "wbudowane w protokół" i może wymagać nieco rzeźby przy jakichś egzotyczniejszych wymaganiach. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Maciek Godek <godek.maciek@gmail.com> |
|---|---|
| Date | 2021-08-25 06:39 -0700 |
| Message-ID | <d080a780-463e-4a11-ac88-80bcba6eb72bn@googlegroups.com> |
| In reply to | #34614 |
środa, 25 sierpnia 2021 o 14:44:04 UTC+2 Mateusz Viste napisał(a): > > Od strony doświadczenia użytkownika można z tego korzystać dokładnie > > tak samo, jak z SVNa, jeśli się chce. > Znaczy patrząc na dwie rewizje mogę rzutem oka stwierdzić, która jest > wcześniejsza, i oszacować mniej więcej o ile? No to git. :) Oczywiście. Git loguje datę każdego commita. Nie wiem, dlaczego to by miało zaskakiwać. > > Co do "chowania wszystkiego przed światem tak długo, jak się da", to > > nie rozumiem. > O lokalne commity chodzi, i o kryjące się za nimi podejście "nie > pokażę co robię póki nie wycackam tego do końca". Nie bardzo rozumiem jaką lepszą alternatywę daje SVN. "Nie scommituję dopóki nie wycykam tego do końca"?
[toc] | [prev] | [next] | [standalone]
| From | heby <heby@poczta.onet.pl> |
|---|---|
| Date | 2021-08-25 16:18 +0200 |
| Message-ID | <sg5jf3$853$1@dont-email.me> |
| In reply to | #34615 |
On 25/08/2021 15:39, Maciek Godek wrote: > Nie bardzo rozumiem jaką lepszą alternatywę daje SVN. > "Nie scommituję dopóki nie wycykam tego do końca"? Takie sytuacje to patlogia w grupach używających SVN. Codziennością są natomiast dziesiętki commitów dzienie w *jawny* branch.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2021-08-25 16:36 +0200 |
| Message-ID | <20210825163615.4d457177@mateusz> |
| In reply to | #34616 |
2021-08-25 o 16:18 +0200, heby napisał: > On 25/08/2021 15:39, Maciek Godek wrote: > > Nie bardzo rozumiem jaką lepszą alternatywę daje SVN. > > "Nie scommituję dopóki nie wycykam tego do końca"? > > Takie sytuacje to patlogia w grupach używających SVN. Codziennością > są natomiast dziesiętki commitów dzienie w *jawny* branch. Całkiem inne podejście, tak. Wpadłem właśnie na ciekawy (acz stary) post. Napisany starannie i z humorem. Podaję linka do lektury przy kawie, gdyby ktoś nie znał. :) https://www.bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/ Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2021-08-24 11:58 -0700 |
| Message-ID | <7082b9d6-7447-4d6a-ac90-aa4ec2f05ec2n@googlegroups.com> |
| In reply to | #34591 |
> Lubię proste i skuteczne narzędzia
Przy pracy jednoosobowej takimi narzędziami są zip oraz unzip. Polecam.
Zwłaszcza, że oprócz historii zmian potrafią zupełnie naturalnie zrobić backup - a to jest *ważniejsze*, niż zabawa w commity.
Nie, lokalny git to nie jest backup.
Jednoosobowy lokalny git ma wartość co najwyżej hobbystyczną albo edukacyjną ("Czy ma Pan doświadczenie z gitem? Tak, od 5 lat."), ale jego użytkowa wartość dodana wynosi epsilon.
To jest bardzo wymowne, że zamiast poprawiać błędy w programie dyskusja jest o wyższości gita nad svnem. :-D
--
Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2021-08-25 09:22 +0200 |
| Message-ID | <20210825092218.2ced2887@mateusz.lan> |
| In reply to | #34597 |
2021-08-24 o 11:58 -0700, Maciej Sobczak napisał:
> > Lubię proste i skuteczne narzędzia
>
> Przy pracy jednoosobowej takimi narzędziami są zip oraz unzip.
Wyczuwam bratnią duszę. Doceniam.
> Polecam. Zwłaszcza, że oprócz historii zmian potrafią zupełnie
> naturalnie zrobić backup - a to jest *ważniejsze*, niż zabawa w
> commity. Nie, lokalny git to nie jest backup.
Z tym jednak zgodzić się nie mogę... Lokalny VCS to oczywiście nie
backup, ale lokalny zestaw plików *.zip też nim nie jest. W obu
przypadkach wypadałoby zrzucić pliki gdzieś na zewnątrz. svn akurat
ma to w standardzie (git też, chyba że ktoś upiera się korzystać z tych
jego "lokalnych" funkcji).
> Jednoosobowy lokalny git ma wartość co najwyżej hobbystyczną albo
> edukacyjną ("Czy ma Pan doświadczenie z gitem? Tak, od 5 lat."), ale
> jego użytkowa wartość dodana wynosi epsilon.
Bez przesady. Lokalny git, svn czy inny rcs to narzędzia które mają
sens nawet lokalny. I oczywiście można zadowolić się zipem, zip-diffem
itd, ale kosztem pewnej wygody użytkowania. Zamiast robić zipa i
kopiować go gdzieś na jakiś serwer po FTP, rsync itp, robię zwyczajne
svn commit i mam pewność, że moje zmiany już się nie zgubią.
Korzystanie z ZIP to również marnotrawstwo miejsca - ten sam plik
będzie w każdym zipie zajmował tyle samo miejsca, choć od wielu lat nie
uległ zmianie. Jest jeszcze jeden aspekt: często zdarza się, że
potrzebuję prześledzić historię jednego pliku (spośród kilkunastu
tysięcy w projekcie) na przestrzeni paru lat. Ciężko mi wyobrazić to
sobie przy milionach plików ZIP.
Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2021-08-25 13:31 -0700 |
| Message-ID | <8d80e627-951f-4b78-8441-b7e76053ed4dn@googlegroups.com> |
| In reply to | #34602 |
> > Przy pracy jednoosobowej takimi narzędziami są zip oraz unzip. > Wyczuwam bratnią duszę. Doceniam. > > Polecam. Zwłaszcza, że oprócz historii zmian potrafią zupełnie > > naturalnie zrobić backup - a to jest *ważniejsze*, niż zabawa w > > commity. Nie, lokalny git to nie jest backup. > Z tym jednak zgodzić się nie mogę... Lokalny VCS to oczywiście nie > backup, ale lokalny zestaw plików *.zip też nim nie jest. Lokalny nie jest. Ale nie napisałem, że lokalny. Nawet pendrive załatwi sprawę łatwiej, niż szarpanie się z VCS. Bo oczywiście nie używamy cały czas tylko jednego pendrive'a. A może jednak Google Drive? Albo Box? A właściwie bez różnicy, bo zip w ogóle nie jest od tego uzależniony. Jest narzędziem tak łatwym w użyciu, że cokolwiek innego jest zawsze dodatkową komplikacją. Dotarło to do mnie, gdy pierwszy raz w życiu zzipowałem lokalne repo gita, żeby zrobić jego backup. Absurdalność tej czynności sprawiła, że to był też ostatni dzień mojego jednoosobowego użytkowania gita. > W obu > przypadkach wypadałoby zrzucić pliki gdzieś na zewnątrz. svn akurat > ma to w standardzie Zdażyło mi się nawet wysłać zipa jako załącznik mailem. Nie, svn nie ma tego w standardzie. Właśnie o to chodzi - o *rozdzielenie* kompetencji. Zamrożenie stanu plików w katalogu to jedna rzecz (potrzebne do historii), składowanie tego stanu to inna rzecz (potrzebne do backupu). Zip jest banalnie skuteczny właśnie przez to, że tych rzeczy nie łączy. > Zamiast robić zipa i > kopiować go gdzieś na jakiś serwer A jeśli nie chcę na "jakiś serwer"? Czemu wszyscy mają obsesję na punkcie wysyłania swojej pracy na "jakiś serwer"? Kiedyś do komputera był podłączony magnetofon i był spokój. :-) > Korzystanie z ZIP to również marnotrawstwo miejsca - ten sam plik > będzie w każdym zipie zajmował tyle samo miejsca, choć od wielu lat nie > uległ zmianie. Technicznie to prawda, ale użytkowo nigdy jeszcze nie doszedłem do tego, żeby martwić się o miejsce na skompresowane pliki źródłowe swojego autorstwa. Może za mało piszę. W każdym razie nie jest to showstopper. > Jest jeszcze jeden aspekt: często zdarza się, że > potrzebuję prześledzić historię jednego pliku (spośród kilkunastu > tysięcy w projekcie) na przestrzeni paru lat. Ciężko mi wyobrazić to > sobie przy milionach plików ZIP. To jest dobry argument. Ale mówimy o użytkowaniu jednoosobowym. W takim kontekście nie zaobserwowałem (u siebie) takich potrzeb. Nawet wtedy, gdy korzystając jednoosobowo z gita, miałem taką możliwość na wyciągnięcie palca. Czyli podobnie jak z brakującym miejscem na dysku, nie jest to scenariusz, który mnie zatrzymuje w pracy. Polecam narzędzi mniej, niż więcej. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2021-08-26 09:40 +0200 |
| Message-ID | <20210826094041.51dec0f1@mateusz.lan> |
| In reply to | #34620 |
2021-08-25 o 13:31 -0700, Maciej Sobczak napisał: > > Z tym jednak zgodzić się nie mogę... Lokalny VCS to oczywiście nie > > backup, ale lokalny zestaw plików *.zip też nim nie jest. > > Lokalny nie jest. Ale nie napisałem, że lokalny. Napisał kolega, że "potrafią zupełnie naturalnie zrobić backup". Na to ja odpowiadam, że nie - nie potrafią. > Nawet pendrive załatwi sprawę łatwiej, niż szarpanie się z VCS. Wyczuwam traumatyczne doświadczenia z VCS (może z gitem? w tym wypadku nie dziwię się nabytym uprzedzeniom). Praca z svnem nie jest żadnym szarpaniem. Powiedziałbym nawet, że w porównaniu do moich doświadczeń sprzed VCS (na dyskietkach, zipach, itp), jest przyjemnością. A pendrive nie załatwi sprawy, z tego prostego powodu że nie jest geograficznie odległy. > Zdażyło mi się nawet wysłać zipa jako załącznik mailem. Mi to się też zdarza (bez kropki). Ale nie jako ersatz backupu, a tym bardziej VCSa. > A jeśli nie chcę na "jakiś serwer"? Czemu wszyscy mają obsesję na > punkcie wysyłania swojej pracy na "jakiś serwer"? Bo to podstawa sensownego backupu. Po każdym 'svn commit' mam przyjemną świadomość, że mój trud już nie zaginie, choćby mi komputer zaraz wybuchł albo dom spłonął. Żadnych pendrajwów, żadnych dyskietek, żadnych parametrów do zipa - tylko svn commit, i po mniej niż sekundzie stan mojego projektu jest zarchiwizowany kilkaset km ode mnie (albo i dalej). > Kiedyś do komputera był podłączony magnetofon i był spokój. :-) Moja mama opowiadała mi kiedyś, jak to pisała pracę magisterską z magnetofonem. Było fajnie póki dziad taśmy nie wciągnął. Skończyło się przepisywaniem wszystkiego na nowo, na podstawie ręcznych notatek. > > Korzystanie z ZIP to również marnotrawstwo miejsca - ten sam plik > > będzie w każdym zipie zajmował tyle samo miejsca, choć od wielu lat > > nie uległ zmianie. > > Technicznie to prawda, ale użytkowo nigdy jeszcze nie doszedłem do > tego, żeby martwić się o miejsce na skompresowane pliki źródłowe > swojego autorstwa. Może za mało piszę. W każdym razie nie jest to > showstopper. Program to przecież nie tylko kod, może zawierać także pliki multimedialne, czcionki, jakieś zewnętrzne biblioteki, stronę www, itp. Zerknąłem na moją pierwszą z brzegu gierkę: http://simplesok.sf.net/ Wielkość trunka 5 MiB. Po skompresowaniu zipem 3.8 MiB. Razy 109 rewizji, to już ponad 400 MiB... Ok, w dobie chmurowych gigabajtów to nie jest "showstopper", ale niemniej dręczyłaby mnie zabawa z 400M zipów dla jednej malutkiej gierki. > To jest dobry argument. Ale mówimy o użytkowaniu jednoosobowym. W > takim kontekście nie zaobserwowałem (u siebie) takich potrzeb. A mi to się zdarzyło co najmniej kilka razy. Głównie w ramach szukania jakiegoś błędu i zastanawiania się dlaczego w pliku bb.c zmieniłem x=1 na x+=1 i w jakich okolicznościach do tego doszło. Nie jest to potrzeba codzienna, ale w stosownym kontekście bardzo się przydaje. > Polecam narzędzi mniej, niż więcej. Też wychodzę z takiego założenia i filozofię bardzo doceniam, niemniej filtr oleju w aucie odkręcam nie (jakże uniwersalnym) młotkiem, tylko wyspecjalizowanym do tego narzędziem. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2021-08-28 13:10 -0700 |
| Message-ID | <53e68cd7-e43c-474a-b45c-926838741553n@googlegroups.com> |
| In reply to | #34624 |
> Napisał kolega, że "potrafią zupełnie naturalnie zrobić backup". Na to > ja odpowiadam, że nie - nie potrafią. No tak. Ostatecznie to jeden z kilku etapów. > A pendrive nie załatwi sprawy, z tego prostego powodu że nie jest > geograficznie odległy. To zależy, jaką sprawę chcesz załatwić. Jest nieskończenie bardziej odległy od lokalnego repo. Nawet jak leży obok. > > A jeśli nie chcę na "jakiś serwer"? Czemu wszyscy mają obsesję na > > punkcie wysyłania swojej pracy na "jakiś serwer"? > Bo to podstawa sensownego backupu. Kiedyś trzymałem swoje pliki na "jakimś serwerze", gdzie admini zadbali o backup serwerów w taki sposób, że serwery nawzajem trzymały swoje kopie. Przyszedł wirus NIMDA i pozamiatał całą serwerownię. Dobrze, że miałem kopię u siebie. Każde rozwiązanie ma swoje anegdoty. > Zerknąłem na moją pierwszą z brzegu gierkę: > http://simplesok.sf.net/ > Wielkość trunka 5 MiB. Po skompresowaniu zipem 3.8 MiB. Razy 109 > rewizji, to już ponad 400 MiB... Ok, No właśnie, to jest dobry przykład. Bo ani 400MB to nie jest temat (najmniejszy pendrive dostępny w sklepie jest kilkadziesiąt razy większy), ani też wcale nie potrzebujesz tych 109 rewizji. Najważniejsza jest ostatnia, potem (dalej wstecz) ich wartość użytkowa maleje w błyskawicznym tempie. > A mi to się zdarzyło co najmniej kilka razy. Głównie w ramach szukania > jakiegoś błędu i zastanawiania się dlaczego w pliku bb.c zmieniłem x=1 > na x+=1 i w jakich okolicznościach do tego doszło. No właśnie. I jeśli masz dokumentację albo chociaż komentarze w kodzie, to nie potrzebujesz historii, żeby na to pytanie odpowiedzieć. A jeśli nie masz, to nawet 109 rewizji, gdzie w 75 pojawia się x+=1, dalej będzie zagadką. > filtr oleju w aucie odkręcam nie (jakże uniwersalnym) młotkiem, tylko > wyspecjalizowanym do tego narzędziem. Zip służy do archiwizacji. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2021-08-30 09:54 +0200 |
| Message-ID | <20210830095459.599686ec@mateusz.lan> |
| In reply to | #34649 |
2021-08-28 o 13:10 -0700, Maciej Sobczak napisał: > wcale nie potrzebujesz tych 109 rewizji. Najważniejsza jest ostatnia, > potem (dalej wstecz) ich wartość użytkowa maleje w błyskawicznym > tempie. Potrzebuję niektórych, ale nie jestem w stanie zawczasu stwierdzić, których dokładnie. Łatwy wgląd w przeszłość jest bardzo przydatny w ramach szukania egzotycznych regresji, o czym już wcześniej wspominałem. > No właśnie. I jeśli masz dokumentację albo chociaż komentarze w > kodzie, to nie potrzebujesz historii, żeby na to pytanie > odpowiedzieć. A jeśli nie masz, to nawet 109 rewizji, gdzie w 75 > pojawia się x+=1, dalej będzie zagadką. Każda zmiana (commit) opatrzona jest komentarzem który mówi, dlaczego ta zmiana została dokonana. Komentarze w kodzie oczywiście też są fajne, ale to zupełnie inny poziom dokumentacji. > > filtr oleju w aucie odkręcam nie (jakże uniwersalnym) młotkiem, > > tylko wyspecjalizowanym do tego narzędziem. > > Zip służy do archiwizacji. Stąd moje zdziwienie, że ktoś nalega aby używać ich do śledzenia/opisywania zmian w kodzie. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2021-08-30 12:10 -0700 |
| Message-ID | <62b6b7e1-d253-45ed-a753-84b6f2950002n@googlegroups.com> |
| In reply to | #34661 |
> > Zip służy do archiwizacji. > Stąd moje zdziwienie, że ktoś nalega aby używać ich do > śledzenia/opisywania zmian w kodzie. Myślę, że nastąpiła tu nadinterpretacja. Może spróbuję to inaczej: w pracy *jednoosobowej* potrzeby archiwizacyjne są bardziej istotne od potrzeby śledzenia zmian. Własnie dlatego (w obu tych kwestiach), że jest się *samemu*. Dlatego, skupiając się na tym, co istotne, porzuciłem rytuał używania gita do absolutnie wszystkiego, bo w takim konkretnym kontekście nie rozwiązuje żadnego mojego problemu. Tu nie chodziło o to, że zip jest lepszy od gita, tylko że jest wtedy bardziej potrzebny. Naprawdę, nie brakuje mi gita w tym, co robię sam. Historie o tym, że jak się czegoś używa w pracy to się potem koniecznie używa tego samego w życiu prywatnym (i jest to miarą profesjonalizmu rozlewającego się na całe życie) wrzucam do jednego worka ze szpanerstwem. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@xyz.invalid> |
|---|---|
| Date | 2021-08-30 21:31 +0200 |
| Message-ID | <20210830213123.1318b852@mateusz.lan> |
| In reply to | #34694 |
2021-08-30 o 12:10 -0700, Maciej Sobczak napisał: > Myślę, że nastąpiła tu nadinterpretacja. Może spróbuję to inaczej: w > pracy *jednoosobowej* potrzeby archiwizacyjne są bardziej istotne od > potrzeby śledzenia zmian. To ja pójdę nawet krok dalej i zaryzykuję tezę, że w wieloosobowej pracy również archiwizacja jest istotniejsza od trackingu. > Tu nie chodziło o to, że zip jest lepszy od gita, tylko że jest wtedy > bardziej potrzebny. Naprawdę, nie brakuje mi gita w tym, co robię sam. Mi gita też nie brakuje :) Natomiast bez svn czułbym się jak cyrkowy akrobata chodzący po linie bez zabezpieczenia (nawet mając archiwizację). Potrafię sobie jednak wyobrazić, że nie każdy musi tego potrzebować. Jeśli ZIPy Cię zadowalają, to spoko - w końcu najważniejsze, że Ty się w tym odnajdujesz. Dodam, że zdarza mi się czasem robić przez kilka dni jakieś prototypy czegoś - do tego nie stawiam svna, tylko działam właśnie na ZIPach (no, w istocie to na tar.xz-ach, ale myśl ta sama). Dopiero kiedy zdecyduję się iść "na serio" w danym kierunku to wrzucam projekt w svn-a. > Historie o tym, że jak się czegoś używa w pracy to się potem > koniecznie używa tego samego w życiu prywatnym (i jest to miarą > profesjonalizmu rozlewającego się na całe życie) wrzucam do jednego > worka ze szpanerstwem. A to chyba nie ode mnie takie bujdy, tylko od kolegi Sebastiana. Ja w życiu prywatnym piszę zupełnie inaczej - bo inne są motywacje i inne cele. Np. testów nie piszę prawie w ogóle, bo zupełnie mnie to nie bawi. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Maciej Sobczak <see.my.homepage@gmail.com> |
|---|---|
| Date | 2021-08-31 11:01 -0700 |
| Message-ID | <fa738e57-ed51-400a-b910-743c922d206bn@googlegroups.com> |
| In reply to | #34696 |
> > Może spróbuję to inaczej: w > > pracy *jednoosobowej* potrzeby archiwizacyjne są bardziej istotne od > > potrzeby śledzenia zmian. > To ja pójdę nawet krok dalej i zaryzykuję tezę, że w wieloosobowej > pracy również archiwizacja jest istotniejsza od trackingu. Jest jego niezbędnym składnikiem. Bo nie da się trackować bez danych historycznych. W pracy wieloosobowej istotne jest też szukanie autora zmiany. W projektach krytycznych (regulowanych) dochodzi jeszcze szukanie tego gościa, co pozwolił na zmianę, bo jego obwinia się nawet bardziej, niż samego autora. Ale pod tym wszystkim zawsze jest potrzeba archiwizacji, której jakąś formę rozproszone VCSy dają w bonusie (bo kod jest w wielu miejscach, więc nie ginie z byle powodu). I jeśli ktoś się skupia na sprawach istotnych, to tej jednej sprawy nie da się zredukować. Dlatego tak niektórych wkurza w tej dyskusji. > Natomiast bez svn czułbym się jak cyrkowy akrobata chodzący po linie bez > zabezpieczenia (nawet mając archiwizację). Właśnie uważam, że to jest *to* zabezpieczenie, któro jest niezbędne. Reszta to ficzery i gadżety, które są potrzebne mniej lub bardziej. Albo wcale. > (no, w istocie to na tar.xz-ach, ale myśl ta sama). Nie chciałem komplikować dyskusji. Zgadza się, u mnie to są tar.gz. :-D > Dopiero > kiedy zdecyduję się iść "na serio" w danym kierunku to wrzucam projekt > w svn-a. No widzisz, to jest ten ciekawy punkt w rozwoju projektu. Bo jak ja się zorientuję, że wyszło mi coś na serio i że do tej pory zrobiłem to *bez* svna, to od razu też stwierdzam, że na tak późnym etapie już nie ma po co tego svna robić. Jakby to powiedzieć - "przegapiłem", bo nie wiedziałem, że się nie da. To oczywiście wynika z kultury pracy, przyzwyczajeń, rytuałów. Np. rozumiem, że ktoś ma naturę archeologa i lubi spędzać czas grzebiąc w historii swojego projektu jak w piaskownicy. Niech sobie ogląda logi, commity, wykresy branchów, statystyki swojej własnej "wydajności", itp. A ja akurat lubię jazdę do przodu a miarą sukcesu jest dla mnie skończony projekt. Polecam, ale nie zmuszam. I co mi zrobisz? :-) > Np. testów nie piszę prawie w ogóle, bo zupełnie mnie to nie > bawi. No i dobra. Testy mają swoją wartość dodaną, ale też jakiś (wieloskładnikowy) koszt. Jeśli koszt jest wyższy, to nie ma sensu ich pisać. U mnie nie wychodzi to jednorodnie między projektami ani nawet w ramach tego samego projektu. Zdarzyło mi się zrobić (ciekawostka: nikt tego nie docenił) zestaw na 100% pokrycia. Zdarzało mi się też nie zrobić ani jednego testu. Ale zawsze miałem archiwum. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | heby <heby@poczta.onet.pl> |
|---|---|
| Date | 2021-08-30 21:42 +0200 |
| Message-ID | <sgjcah$rs4$1@dont-email.me> |
| In reply to | #34694 |
On 30/08/2021 21:10, Maciej Sobczak wrote: > Myślę, że nastąpiła tu nadinterpretacja. Może spróbuję to inaczej: w pracy *jednoosobowej* potrzeby archiwizacyjne są bardziej istotne od potrzeby śledzenia zmian. Własnie dlatego (w obu tych kwestiach), że jest się *samemu*. Brednia. Już wyjasniałem że przy pracy jednosobowej i wieloosobowej zagadnienie jest takie samo: dlaczego zmieniona zostala 3 lata temu ta linijka, kiedy to nastapiło i co jeszcze zostało zmienione w ramach tej wrzuty, co tam bylo wcześniej. To, czy zmienił to A czy B nie ma znaczenia. Możesz założyć że wszkie zmiany dokonał A i będzie to tak samo użyteczne w pracy jednoosobowej jak i wieloosobowej. W wielu systemach kontroli wersji, jeśli pozbyłbys się informacji kto wrzucił daną zmianę, metodyka odszukania regresji i jej zrozumienia niczym się nie będzie różnić. Skupiasz się na nieistotnym detalu, jakim jest wieloosobowość i napompowałeś go do rangi decydującej. On nie musi istnieć, wszystcy autorzy mogą być 1 loginem, nic to nie zmieni w sposobie pracy, co najwyżej będzie mniej docinek "znowu Heniek spi...". > Dlatego, skupiając się na tym, co istotne, porzuciłem rytuał używania gita do absolutnie wszystkiego, bo w takim konkretnym kontekście nie rozwiązuje żadnego mojego problemu. Tu nie chodziło o to, że zip jest lepszy od gita, tylko że jest wtedy bardziej potrzebny. Naprawdę, nie brakuje mi gita w tym, co robię sam. Ale dlaczego polecasz go innym? Skoro nie ma zalet na gita, a jedynie same wady to jaki masz cel sugerowania średniowiecznej metody komukolwiek skoro obok jest darmowa metoda robiąca to lepiej pod każdym względem, wydajności, miejsca na dysku, prędkości sprawdzań, separacji zagadnień, itd itp? > Historie o tym, że jak się czegoś używa w pracy to się potem koniecznie używa tego samego w życiu prywatnym (i jest to miarą profesjonalizmu rozlewającego się na całe życie) wrzucam do jednego worka ze szpanerstwem. Ja zaś z rozsądkiem. Skoro sprawdza się w dużej skali, nic nie kosztuje i jest nieporównywalnie lepsze od dziadowania na ZIPach to założe że to stawianie ZIPa jako równorzędnego mechanizmu do zabaw w domu jest tylko żałosną próbą wyróżnienia się z tłumu. Coś jak poruszanie się po mieście furmanką. Ekstrawaganckie, bezsensowne ale "wystarczające" do pojechania pod Tesco po bułki. Może własnie o to chodzi. Taki dick-waving: patrzcie, jaką mam ekstrawagancką metodę, nie ma żadnych zalet ale za to jest gorsza od gita.
[toc] | [prev] | [next] | [standalone]
| From | slawek <x.y@org.org> |
|---|---|
| Date | 2021-10-17 17:27 +0200 |
| Message-ID | <skhfca$nk1$2@news.icm.edu.pl> |
| In reply to | #34694 |
Maciej Sobczak <see.my.homepage@gmail.com> Wrote in message: > Historie o tym, że jak się czegoś używa w pracy to się potem koniecznie używa tego samego w życiu prywatnym (i jest to miarą profesjonalizmu rozlewającego się na całe życie)... No no - Sobczak w pracy używa rozumu... ----Android NewsGroup Reader---- http://usenet.sinaapp.com/
[toc] | [prev] | [next] | [standalone]
| From | heby <heby@poczta.onet.pl> |
|---|---|
| Date | 2021-08-26 09:55 +0200 |
| Message-ID | <sg7hee$ubs$1@dont-email.me> |
| In reply to | #34620 |
On 25/08/2021 22:31, Maciej Sobczak wrote: > Nawet pendrive A jak się popsuje? > załatwi sprawę łatwiej, niż szarpanie się z VCS. Nie. Odpalanie działającego, nowego repozytorium w SVN na lokalnym dysku jest jednym kliknięciem w TortoiseSVN. Reszta, to darmowy bonus. Szczególnie dla progrmisty. W porównaniu z szarpaniem się z plikami ZIP, to SVN urasta do zbawcy ludzkości pod względem *łatwości* pracy. Dwa klinknięcia i masz backup z historią, revertem, blame, opisem, sandboxem. Proponowanie ZIPa zamiast jakiegoś VCS dla *programisty* urąga logice.
[toc] | [prev] | [next] | [standalone]
| From | slawek <x.y@org.org> |
|---|---|
| Date | 2021-10-17 17:32 +0200 |
| Message-ID | <skhfms$nk1$3@news.icm.edu.pl> |
| In reply to | #34625 |
heby <heby@poczta.onet.pl> Wrote in message: >Proponowanie ZIPa zamiast jakiegoś VCS dla *programisty* urąga logice. Ajtam. Raczej trollowanie. Kiepskie, bo mało wiarygodne. ----Android NewsGroup Reader---- http://usenet.sinaapp.com/
[toc] | [prev] | [next] | [standalone]
| From | kriters <kritersi@o2.pl> |
|---|---|
| Date | 2021-08-25 23:00 +0200 |
| Message-ID | <6126af7d$0$541$65785112@news.neostrada.pl> |
| In reply to | #34597 |
W dniu 24.08.2021 o 20:58, Maciej Sobczak pisze:
>> Lubię proste i skuteczne narzędzia
> Przy pracy jednoosobowej takimi narzędziami są zip oraz unzip. Polecam.
> Zwłaszcza, że oprócz historii zmian potrafią zupełnie naturalnie zrobić backup - a to jest *ważniejsze*, niż zabawa w commity.
> Nie, lokalny git to nie jest backup.
>
> Jednoosobowy lokalny git ma wartość co najwyżej hobbystyczną albo edukacyjną ("Czy ma Pan doświadczenie z gitem? Tak, od 5 lat."), ale jego użytkowa wartość dodana wynosi epsilon.
Co za kompletna bzdura. "Praca" z zipami to koszmar do którego nikt
normalny nie chce wracać. Zipy to się mogą co najwyżej tworzyć z
automatu ale lepiej żeby nikt nie musiał nigdy do nich zaglądać.
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | pl.comp.programming
csiph-web