| 1 |
On 26-03-2009 16:01:52 +0100, Jonas Bernoulli wrote: |
| 2 |
> >> this may be true of you, but it's also likely to introduce unneeded |
| 3 |
> >> complexity into the program depending on exactly how it's set up. |
| 4 |
> >> actually I think it'd be best if it were mostly transparent to the |
| 5 |
> >> user, like cfg-update. |
| 6 |
> > |
| 7 |
> > then you loose the entire asset of this proposal, I think ;) |
| 8 |
> |
| 9 |
> These plumbing commands can be used to implement alternative |
| 10 |
> porceclain, which has happened in the past. This is also what I would |
| 11 |
> do with confsink. This is not exclusive however - one can still use |
| 12 |
> the git porceclain to operate on the configuration files maintained by |
| 13 |
> confsink. Or one can use the plumbing commands where necessary. |
| 14 |
> |
| 15 |
> So most people would not have to use git (plumbing and/or porceclain) |
| 16 |
> directly they just use an extended emerge which will take care of |
| 17 |
> automating things that can be automated and the confsink command-line |
| 18 |
> utilities (cfs) to commit changes. |
| 19 |
|
| 20 |
Your original approach (or as I recall it) mentioned the benefit of |
| 21 |
people already being accustomed to $VCS. If you hide away the $VCS bits |
| 22 |
again, you lose this valuable point. |
| 23 |
|
| 24 |
One could wonder why one would need a version history for config files |
| 25 |
at all in this case, and if not we better revive/finish libconf[1]. |
| 26 |
|
| 27 |
> Next step would be to get used to 'merge', 'branch', 'checkout', |
| 28 |
> 'commit' (deliberatly leaving 'add' out :-). These might have |
| 29 |
> different names in different vcs but it's hardly to much to ask to |
| 30 |
> learn another name for a command. Also git can be customized to define |
| 31 |
> aliases for it's commands. So confsink could be distributed with some |
| 32 |
> sets of commands whose names are specially tailored the the names |
| 33 |
> these command have in the prevered vcs. |
| 34 |
|
| 35 |
Basically, it seems to me you just make it hard for yourself, and for a |
| 36 |
user. If I am used to say git, why not provide me with all of git's |
| 37 |
magic so I can do whatever voodoo to my config files like I want, when I |
| 38 |
have to "merge updates"? Adding your layer might be nicer from a tool |
| 39 |
perspective, but it doesn't add anything, IMO. Leaving the merging up |
| 40 |
to what $USER is used to, also better integrates with me wanting to use |
| 41 |
$VCS for the entire stuff. Eventually you'll just end up creating a |
| 42 |
etc-update backend that instead of (re)moving files, just commits them. |
| 43 |
|
| 44 |
> >> > I for one can much easier mess around with CVS and SVN, |
| 45 |
> >> > then with bzr, git, hg, etc. |
| 46 |
> |
| 47 |
> Coming back to this. While I agree that it might be desirable to |
| 48 |
> support alternative distributed vcs as backend I think that: |
| 49 |
> |
| 50 |
> 1. Only git is truely suitable for the task. |
| 51 |
|
| 52 |
Depends how you look at it :) |
| 53 |
|
| 54 |
> 2. Non-distributed vc is absolutely not suited. Especially when it |
| 55 |
> comes to sharing configuration between users. |
| 56 |
|
| 57 |
Well, ehm... a PORTAGE_BINHOST is a master/slave thinghy, if not sole |
| 58 |
master. SYNC, idem. What's wrong with a nice central VCS storage where |
| 59 |
the administrator makes changes which are then rolled out to the entire |
| 60 |
cluster? I would even prefer the hosts not to be able to make any |
| 61 |
changes because that is a maintenance nightmare. |
| 62 |
I can imagine cases where you would like to have that though, but just |
| 63 |
to illustrate that distributed vc is not heaven or something. |
| 64 |
|
| 65 |
> 3. Supporting multiple backends adds unnecessary complexity... |
| 66 |
|
| 67 |
Yeah, but what if git becomes out of fashion (which it seems to be at |
| 68 |
the moment)? Rewrite the entire thing, or get stuck with it? Also, |
| 69 |
consider who would benefit the most from something like this, probably |
| 70 |
the more advanced user who is familiar with some $VCS. |
| 71 |
|
| 72 |
> 4. ... and would limit confsink to the least common denominator of the |
| 73 |
> various backends. |
| 74 |
|
| 75 |
Depends how you interface it. I'd say, don't! Just define how the |
| 76 |
updates are pushed and where you can merge diffs in from. |
| 77 |
|
| 78 |
> 5. git porceclain has improved a lot, it is not hard to learn, and you |
| 79 |
> should learn it (and or other dvcs). |
| 80 |
|
| 81 |
This is not about me messing around with $VCS, I think. |
| 82 |
|
| 83 |
|
| 84 |
[1] http://savannah.nongnu.org/projects/libconf/ |
| 85 |
|
| 86 |
|
| 87 |
-- |
| 88 |
Fabian Groffen |
| 89 |
Gentoo on a different level |
Archives