| 1 |
Hi all |
| 2 |
|
| 3 |
On Thu, Mar 26, 2009 at 12:19, Fabian Groffen <grobian@g.o> wrote: |
| 4 |
> On 26-03-2009 07:17:57 -0400, Caleb Cushing wrote: |
| 5 |
>> On Thu, Mar 26, 2009 at 4:18 AM, Fabian Groffen <grobian@g.o> wrote: |
| 6 |
>> > I for one can much easier mess around with CVS and SVN, |
| 7 |
>> > then with bzr, git, hg, etc. |
| 8 |
|
| 9 |
People grow accustomed to some vcs and then like to stick to it. My |
| 10 |
favorite is git no doubt. I have also used bzr and hg in the past, but |
| 11 |
not to do any fancy stuff. |
| 12 |
|
| 13 |
Git is my favorite for a reason which is that it is perfectly suited |
| 14 |
to be used to implement things other than version control for |
| 15 |
developing some application. It has been deliberately designed to |
| 16 |
allow implementing alternative use cases. It's set of commands is |
| 17 |
split into two categories: porceclain and plumbing. While the |
| 18 |
porceclain is designed to be sufficient in most cases, these commands |
| 19 |
use the plumbing commands which implement low-level access to the |
| 20 |
object stored by git. |
| 21 |
|
| 22 |
>> this may be true of you, but it's also likely to introduce unneeded |
| 23 |
>> complexity into the program depending on exactly how it's set up. |
| 24 |
>> actually I think it'd be best if it were mostly transparent to the |
| 25 |
>> user, like cfg-update. |
| 26 |
> |
| 27 |
> then you loose the entire asset of this proposal, I think ;) |
| 28 |
|
| 29 |
These plumbing commands can be used to implement alternative |
| 30 |
porceclain, which has happened in the past. This is also what I would |
| 31 |
do with confsink. This is not exclusive however - one can still use |
| 32 |
the git porceclain to operate on the configuration files maintained by |
| 33 |
confsink. Or one can use the plumbing commands where necessary. |
| 34 |
|
| 35 |
So most people would not have to use git (plumbing and/or porceclain) |
| 36 |
directly they just use an extended emerge which will take care of |
| 37 |
automating things that can be automated and the confsink command-line |
| 38 |
utilities (cfs) to commit changes. |
| 39 |
|
| 40 |
Without making much use of all the things I plan to implement confsink |
| 41 |
is just etc-update with the addes ability to go back to older versions |
| 42 |
and a way to list all packages which have been customized. Confsink |
| 43 |
should be hardly noticable to the user in case he does not want to use |
| 44 |
it's functionality beyond things that automatically happen. |
| 45 |
|
| 46 |
Next step would be to get used to 'merge', 'branch', 'checkout', |
| 47 |
'commit' (deliberatly leaving 'add' out :-). These might have |
| 48 |
different names in different vcs but it's hardly to much to ask to |
| 49 |
learn another name for a command. Also git can be customized to define |
| 50 |
aliases for it's commands. So confsink could be distributed with some |
| 51 |
sets of commands whose names are specially tailored the the names |
| 52 |
these command have in the prevered vcs. |
| 53 |
|
| 54 |
>> > I for one can much easier mess around with CVS and SVN, |
| 55 |
>> > then with bzr, git, hg, etc. |
| 56 |
|
| 57 |
Coming back to this. While I agree that it might be desirable to |
| 58 |
support alternative distributed vcs as backend I think that: |
| 59 |
|
| 60 |
1. Only git is truely suitable for the task. |
| 61 |
2. Non-distributed vc is absolutely not suited. Especially when it |
| 62 |
comes to sharing configuration between users. |
| 63 |
3. Supporting multiple backends adds unnecessary complexity... |
| 64 |
4. ... and would limit confsink to the least common denominator of the |
| 65 |
various backends. |
| 66 |
5. git porceclain has improved a lot, it is not hard to learn, and you |
| 67 |
should learn it (and or other dvcs). |
| 68 |
|
| 69 |
-- Jonas |
Archives