Re: Re: etckeeper - keeping /etc under version control

2014-04-11 Thread Grzegorz Szyszlo
At now "svn create .svn directory in all subirectories" isn't true. 
Version 1.8.8 svn creates only ONE .svn directory in root repo directory.

Then now this is good provider for etckeeper.
Another problem, git is more complicated when we work on external 
repository. This is needed for restoring configuration when server 
completly fire.
Other way, git keeps all versions in local directory. This takes place 
in /etc/ directory. I know, I can move .git everywere and symlink it.


SVN keeps all on external directory. This is better behavior for etckeeper.

The last one. SVN can store data in external svn directory. 
Unfortunately GIT can't works like that.


Then I'm strongly waiting for subversion support in etckeeper. It looks 
easy to make it :)




--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/5347e605.2080...@gmail.com



Re: etckeeper - keeping /etc under version control

2009-07-08 Thread Joseph Rawson
On Wednesday 08 July 2009 01:42:56 Scott Gifford wrote:
> Peter Jordan  writes:
> > Suno Ano, Wed Jun 17 2009 19:07:31 GMT+0200 (CEST):
> >>  Peter> Metadata = data stored in .svn/ ?
> >> yes, problem is, Subversion does not have one directory i.e. one
> >> .svn/
> >> at the root of the project where is stores metadata but it scatters them
> >> all over the place which is very annoying. Git only has one .git/ at the
> >> project root at that is it
> >> http://sunoano.name/ws/public_xhtml/scm.html#why_git --> metadata
> >
> > svk does not store the metadata in the project path at all
>
> Being able to use something like etckeeper with svn (maybe via svk)
> would be very useful to me, has anybody tried this?
>
> Scott.

I wrote a program a few years ago that uses svn to help keep track of /etc.

The name of the program, unsurprisingly is etcsvn.

I stopped using it around 2007, choosing to use paella to help handle some of 
this.  I found that keeping track of /etc in its entirety was somewhat 
burdensome (this was at a time when packages were placing things in /etc that 
shouldn't have been there, such as gconf).

I'm not sure how loosely you are using the phrase "like etckeeper", but I can 
give you a short synopsis of similarities and differences.

etckeeper:
uses directories that's easy to add scripts to make it very flexible
(this could be done with etcsvn, with a little bit of work)

hooks into apt to track changes to /etc made by upgrading packages
(I never thought about this when I wrote etcsvn, but it would be a nice 
addition)

etcsvn:
/etc is an export, not a working copy (I was concerned about keeping the / 
partition small and a working copy is over twice the size).

the working copy is kept in /var/lib/etcsvn (or somewhere under there, I can't 
remember now)

the working copy is only readable by root

etcsvn sets a umask of 077 so exports back to /etc can be done securely

etcsvn uses svn properties to keep track of ownership, file permissions, and 
mtime (this could be extended to keep track of other metadata, including 
extended attributes.  I knew nothing about xattr when I wrote this).

since subversion can handle empty directories, etcsvn can do so as well

since subversion can do a checkout of a subdirectory in a repository, you can 
keep /etc from multiple machines in the same repository (in these cases the 
repository was never accessible from those machines, I used to keep it on my 
laptop and use ssh port-forwarding and agent forwarding to access the 
repository on those machines)

etcsvn doesn't handle authentication to the repository (I normally used ssh to 
handle this)

etcsvn may need some work to use https methods better

etcsvn uses an etcsvn.conf file in its working copy, where you specify the 
directories and/or files to be tracked.  This means that you can also track 
files and/or directories in /var or elsewhere, and keep ownership, 
permissions, and mtime straight.



I haven't touched the code in a long time.  It may not work as it used to.  
After looking at it, the last thing I did was a few weeks ago, when I changed 
all the os.system calls to use subprocess instead (something I've been trying 
to do across the board with all my python code).

I have been also thinking about using another strategy, instead of keeping all 
of /etc in subversion.  Basically like this:

get package list through dpkg --get-selections
conffiles = list()
tracked_files = list()
for package in packages:
dpkg --status (get the conffiles and add them to the list)

walk through /etc
check if file is in conffiles list
if file in conffiles:
check md5sum
if md5sum differs:
tracked_files.append(file)
else:
check file in ignored_list
if not in ignored_list:
tracked_files.append(file)
if file in track_anyway_list:
tracked_files.append(file)

add tracked files to svn

This would keep the amount of files that were being tracked down to a minimum.

Anyway, if you are interested in it, look it over, maybe try it out and let me 
know.  It may be outdated, but bringing it back up to date shouldn't be too 
difficult.



-- 
Thanks:
Joseph Rawson


signature.asc
Description: This is a digitally signed message part.


Re: etckeeper - keeping /etc under version control

2009-07-08 Thread Suno Ano
The CSS has always just been a low priority plus, I am by no means a
"webdesigner" ;-]

I am utterly open to suggestions regarding CSS. How would some CSS guru
alter http://sunoano.name/misc/css/default.css in order to make it
better?

The HTML itself, I cannot really change as it comes out of Emacs (I use
Emacs + Muse to write the whole shebang)
http://www.emacswiki.org/cgi-bin/wiki/EmacsWikiMode



pgp6EgwlVUxQy.pgp
Description: PGP signature


Re: etckeeper - keeping /etc under version control

2009-07-08 Thread Barclay, Daniel
Suno Ano wrote:
> Hi folks,
> 
>  Chris> Actually I took a peek with Seamonkey as well and apart from
>  Chris> white rabbits that I could live without - and other prettifying
>  Chris> that I definitely will live without :-) everything renders OK.
> 
> http://sunoano.name/ws/public_xhtml/faq.html#your_site_css_sucks_mate!_i_have_to_scroll!

Your page says:

 >  Your Site CSS sucks mate! I have to scroll!
 >
 >You are talking about screen width.

(Actually, no; we are not talking about _screen_ width--we are
talking about _browser_ _window_ (or pane) width.  Remember that
browser windows aren't always full-screen windows.)

 >Well, I decided to go with
 >a floating CSS style rather than fixed width — this is good because
 > it fills peoples screens no matter what the screen width is.

That's a good intent, but you didn't actually implement it.  Your
pages do not actually "float" (adjust in width)well.

Some parts do work.  For example, the three paragraphs at the top,
starting "Connector, geek, ...", and the glass-of-milk image adjust
fairly well.

However, much of the rest of the page does not.  For example, none
of the text in the center column in the rest of the page wraps to
fit the browser window.  (Narrow your window to see what happens.)


The cause of the problem seems to be that you used an HTML table
(or CSS table formatting) to implement the columns.

The combination of table formatting and putting images (or other
fixed-width content) in the column forces the column width, and
in turn text width, to the width the image, not letting a readers'
browsers try to wrap the text to fit each reader's chosen browser
window width.

(When an image or fixed-width content is not in a table column,
even if that image requires horizontal scrolling to be viewed,
the browser can wrap the rest of the text paragraphs to fit within
the browser pane, and their text is readable without repeated
horizontal scrolling.)

Try using the CSS "float" feature for you left-side navigation bar
("Home", "FAQs", etc.) and your right-side "Table Of Content"
column).

Then you probably won't need to use  elements (or CSS
table-formatting properties), and any images that overflow
somebody's browser pane won't force all the text to overflow too.



Daniel
-- 
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]




Re: etckeeper - keeping /etc under version control

2009-07-08 Thread Andrei Popescu
[this was meant for the list]

On Wed,08.Jul.09, 12:35:20, Andrei Popescu wrote:
> On Wed,08.Jul.09, 02:42:56, Scott Gifford wrote:
> > 
> > Being able to use something like etckeeper with svn (maybe via svk)
> > would be very useful to me, has anybody tried this?
> 
> See #458078
> 
> Regards,
> Andrei
> -- 
> If you can't explain it simply, you don't understand it well enough.
> (Albert Einstein)


signature.asc
Description: Digital signature


Re: etckeeper - keeping /etc under version control

2009-07-08 Thread Suno Ano
 Scott> Being able to use something like etckeeper with svn (maybe via
 Scott> svk) would be very useful to me, has anybody tried this?

I never tried myself i.e. I only use git as backend. Looks like only those

,[ grep -A3 VCS /etc/etckeeper/etckeeper.conf ]
| # The VCS to use.
| # VCS="hg"
| VCS="git"
| # VCS="bzr"
| # VCS="darcs"
|
| # Options passed to git commit when run by etckeeper.
| #GIT_COMMIT_OPTIONS=""
`

VCS systems are supported ... no svn as you can see. Judging from above,
those are all being decentralized, I suppose svn (even with svk on top)
is not supported.


pgpnClsrVAhKp.pgp
Description: PGP signature


Re: etckeeper - keeping /etc under version control

2009-07-08 Thread Suno Ano
Andrei> It does simplify searches within a page, but it might take too
Andrei> long to load over a slow connection.

Actually I think all content on one page simplifies searching a lot
more; we can use Ctrl+f with firefox/iceweasel for example.


pgpyzJZB50rgm.pgp
Description: PGP signature


Re: etckeeper - keeping /etc under version control

2009-07-08 Thread Andrei Popescu
On Wed,08.Jul.09, 07:38:10, Suno Ano wrote:
> Hi folks,
> 
>  Chris> Actually I took a peek with Seamonkey as well and apart from
>  Chris> white rabbits that I could live without - and other prettifying
>  Chris> that I definitely will live without :-) everything renders OK.
> 
> http://sunoano.name/ws/public_xhtml/faq.html#your_site_css_sucks_mate!_i_have_to_scroll!
 
Even at 1680x1050 there is a horizontal scrollbar...

>  Chris> To the OP: a rather amazing web site. Maybe the 57-page long scm
>  Chris> article could be structured in chapters on separate pages -
>  Chris> that's just me, of course.
> 
> well, cutting a page into many smaller pages is one of two possible
> things one could do ... I opted for "all on one page" which is the
> second possible thing to do. I am not going to change it now ... even if
> I did, there would then be folks asking be to put all on one page :)

It does simplify searches within a page, but it might take too long to 
load over a slow connection.

Regards,
Andrei
P.S. Please don't break the quoting in your posts, it makes your mails 
more difficult to read in a mailer who can distinguish between different 
levels of quoting
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


signature.asc
Description: Digital signature


Re: etckeeper - keeping /etc under version control

2009-07-07 Thread Scott Gifford
Peter Jordan  writes:

> Suno Ano, Wed Jun 17 2009 19:07:31 GMT+0200 (CEST):
>>  Peter> Metadata = data stored in .svn/ ?
>> yes, problem is, Subversion does not have one directory i.e. one
>> .svn/
>> at the root of the project where is stores metadata but it scatters them
>> all over the place which is very annoying. Git only has one .git/ at the
>> project root at that is it
>> http://sunoano.name/ws/public_xhtml/scm.html#why_git --> metadata
>>
>
> svk does not store the metadata in the project path at all

Being able to use something like etckeeper with svn (maybe via svk)
would be very useful to me, has anybody tried this?

Scott.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: etckeeper - keeping /etc under version control

2009-07-07 Thread Suno Ano
Hi folks,

 Chris> Actually I took a peek with Seamonkey as well and apart from
 Chris> white rabbits that I could live without - and other prettifying
 Chris> that I definitely will live without :-) everything renders OK.

http://sunoano.name/ws/public_xhtml/faq.html#your_site_css_sucks_mate!_i_have_to_scroll!

 Chris> To the OP: a rather amazing web site. Maybe the 57-page long scm
 Chris> article could be structured in chapters on separate pages -
 Chris> that's just me, of course.

well, cutting a page into many smaller pages is one of two possible
things one could do ... I opted for "all on one page" which is the
second possible thing to do. I am not going to change it now ... even if
I did, there would then be folks asking be to put all on one page :)



pgpAKgEhpKgWD.pgp
Description: PGP signature


Re: etckeeper - keeping /etc under version control

2009-07-07 Thread Chris Jones
On Tue, Jul 07, 2009 at 08:14:57PM EDT, John Hasler wrote:
> CJ writes:
> > Maybe use a mature browser such as ELinks - displays fine here.
> 
> The problem is that some of us have less than perfect vision 

"And poor old Homer, blind, blind as a bat, (..)
 Ear, ear for the sea-surge, murmer of old men's voices.. "

etc.

Good catch, though, I indeed have excellent vision and being a pauper
condemned to the smaller screen sizes, I  do use tiny fonts.

:-)

CJ


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: etckeeper - keeping /etc under version control

2009-07-07 Thread John Hasler
CJ writes:
> Maybe use a mature browser such as ELinks - displays fine here.

The problem is that some of us have less than perfect vision and
consequently use a minimum type size larger than that assumed by the site
designer.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: etckeeper - keeping /etc under version control

2009-07-07 Thread Chris Jones
On Tue, Jul 07, 2009 at 04:53:25PM EDT, Barclay, Daniel wrote:
> Suno Ano wrote:
> > Hi folks,
> > 
> > I wrote an article about etckeeper... that nifty thing that allows to
> > keep /etc under version control and thus "rollback" in case something
> > bad happens during an upgrade or so.
> > 
> > http://sunoano.name/ws/public_xhtml/scm.html#etckeeper
> 
> Could you fix your web page formatting so it doesn't prevent one's
> browser from wrapping text to fit the viewport?

Maybe use a mature browser such as ELinks - displays fine here.

Actually I took a peek with Seamonkey as well and apart from white
rabbits that I could live without - and other prettifying that I
definitely will live without :-) everything renders OK.

To the OP: a rather amazing web site. Maybe the 57-page long scm article
could be structured in chapters on separate pages - that's just me, of
course.

CJ


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: etckeeper - keeping /etc under version control

2009-07-07 Thread Boyd Stephen Smith Jr.
In <4a53b5c5.7000...@fgm.com>, Barclay, Daniel wrote:
>Suno Ano wrote:
>> Hi folks,
>>
>> I wrote an article about etckeeper... that nifty thing that allows to
>> keep /etc under version control and thus "rollback" in case something
>> bad happens during an upgrade or so.
>>
>> http://sunoano.name/ws/public_xhtml/scm.html#etckeeper
>
>Could you fix your web page formatting so it doesn't prevent one's
>browser from wrapping text to fit the viewport?

Could you fix your CSS so the page is readable if the user's default is 
light text on a dark background?  One CSS "best practice" is to always 
specify a background color when specify a foreground color.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/



signature.asc
Description: This is a digitally signed message part.


Re: etckeeper - keeping /etc under version control

2009-07-07 Thread Barclay, Daniel
Suno Ano wrote:
> Hi folks,
> 
> I wrote an article about etckeeper... that nifty thing that allows to
> keep /etc under version control and thus "rollback" in case something
> bad happens during an upgrade or so.
> 
> http://sunoano.name/ws/public_xhtml/scm.html#etckeeper

Could you fix your web page formatting so it doesn't prevent one's
browser from wrapping text to fit the viewport?

Daniel
-- 
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]




Re: etckeeper - keeping /etc under version control

2009-06-25 Thread Joseph Rawson
On Wednesday 17 June 2009 09:28:36 Oliver Schneider wrote:
> > > I do not see how this solves the metadata issue if you use a version
> > > control system directly without the smartness etckeeper brings to the
> > > table e.g. by using its .gitignore settings.
> > >
> > > svk is an attempt to inject the notion of being a decentralized scm
> > > into a centralized one (which svn happens to be) ... that has nothing
> > > to do with putting /etc under version control
> >
> > metadata = data stored in .svn/ ?
>
> Yes. In this case all the metadata stored by SVN.
>
> Certainly there is more metadata which is nowadays simply ignored by many
> VCS, partially due to the discrepancies between different platforms and
> there implementation of, say, file permissions, partially out of negligence
> or lack of a *proper* solution.
>
I considered that svn used the *proper* solution with it properties system.  
Using subversion properties allows you to store arbitrary metadata on a per 
file/directory basis.  This allows each svn client to handle that metadata in 
the most appropriate way, without having the application try to decide this 
for you (It does make some assumptions for you, such as svn:executable, which 
doesn't make sense on windows platforms, but is necessary for unixy systems.

I solved most of these problems a few years ago by making a program, etcsvn,  
to handle this stuff for me.  After using it for around a year or so, with 
many machines, I found that it was less hassle to keep from placing the 
complete /etc directory in subversion, and just track certain files (i.e. 
those that were changed or new).
> Also, as far as I understand SVK it's using only one Subversion library,
> not the whole thing. It's not just a distributed SVN in that sense ... also
> see: 
>
> // Oliver

-- 
Thanks:
Joseph Rawson


signature.asc
Description: This is a digitally signed message part.


Re: etckeeper - keeping /etc under version control

2009-06-17 Thread Peter Jordan

Suno Ano, Wed Jun 17 2009 19:07:31 GMT+0200 (CEST):

 Peter> Metadata = data stored in .svn/ ?

yes, problem is, Subversion does not have one directory i.e. one .svn/
at the root of the project where is stores metadata but it scatters them
all over the place which is very annoying. Git only has one .git/ at the
project root at that is it

http://sunoano.name/ws/public_xhtml/scm.html#why_git --> metadata



svk does not store the metadata in the project path at all

PJ


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org




Re: etckeeper - keeping /etc under version control

2009-06-17 Thread Suno Ano

 Peter> Metadata = data stored in .svn/ ?

yes, problem is, Subversion does not have one directory i.e. one .svn/
at the root of the project where is stores metadata but it scatters them
all over the place which is very annoying. Git only has one .git/ at the
project root at that is it

http://sunoano.name/ws/public_xhtml/scm.html#why_git --> metadata



pgp4dvhWSXWtT.pgp
Description: PGP signature


Re: etckeeper - keeping /etc under version control

2009-06-17 Thread Oliver Schneider
> > I do not see how this solves the metadata issue if you use a version
> > control system directly without the smartness etckeeper brings to the
> > table e.g. by using its .gitignore settings.
> > 
> > svk is an attempt to inject the notion of being a decentralized scm into
> > a centralized one (which svn happens to be) ... that has nothing to do
> > with putting /etc under version control
> > 
> 
> metadata = data stored in .svn/ ?
Yes. In this case all the metadata stored by SVN.

Certainly there is more metadata which is nowadays simply ignored by many VCS, 
partially due to the discrepancies between different platforms and there 
implementation of, say, file permissions, partially out of negligence or lack 
of a *proper* solution.

Also, as far as I understand SVK it's using only one Subversion library, not 
the whole thing. It's not just a distributed SVN in that sense ... also see: 


// Oliver


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Re: etckeeper - keeping /etc under version control

2009-06-17 Thread Peter Jordan

Suno Ano, Tue Jun 16 2009 12:37:28 GMT+0200 (CEST):

 Peter> You can use svk instead of svn

I do not see how this solves the metadata issue if you use a version
control system directly without the smartness etckeeper brings to the
table e.g. by using its .gitignore settings.

svk is an attempt to inject the notion of being a decentralized scm into
a centralized one (which svn happens to be) ... that has nothing to do
with putting /etc under version control



metadata = data stored in .svn/ ?


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org




Re: etckeeper - keeping /etc under version control

2009-06-16 Thread Suno Ano

 Peter> You can use svk instead of svn

I do not see how this solves the metadata issue if you use a version
control system directly without the smartness etckeeper brings to the
table e.g. by using its .gitignore settings.

svk is an attempt to inject the notion of being a decentralized scm into
a centralized one (which svn happens to be) ... that has nothing to do
with putting /etc under version control



pgphhg2X4hRuv.pgp
Description: PGP signature


Re: etckeeper - keeping /etc under version control

2009-06-16 Thread Peter Jordan

Suno Ano, Sun Jun 14 2009 15:04:28 GMT+0200 (CEST):

 Oliver> Thanks a lot. This is great. I had been looking for some tool
 Oliver> like that for a while and had some failed attempts with SVN
 Oliver> (failed with respect to the metadata).

yes, SVN, about that ... see
http://sunoano.name/ws/public_xhtml/scm.html#why_git


 Oliver> Thanks for the helpful article and thanks for the pointer to
 Oliver> the tool.

I am glad you like it




you can use svk instead of svn

pj


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org




Re: etckeeper - keeping /etc under version control

2009-06-14 Thread Suno Ano

 Oliver> Thanks a lot. This is great. I had been looking for some tool
 Oliver> like that for a while and had some failed attempts with SVN
 Oliver> (failed with respect to the metadata).

yes, SVN, about that ... see
http://sunoano.name/ws/public_xhtml/scm.html#why_git


 Oliver> Thanks for the helpful article and thanks for the pointer to
 Oliver> the tool.

I am glad you like it




pgpbvdDcu2JWi.pgp
Description: PGP signature


Re: etckeeper - keeping /etc under version control

2009-06-14 Thread Oliver Schneider
> I wrote an article about etckeeper... that nifty thing that allows to
> keep /etc under version control and thus "rollback" in case something
> bad happens during an upgrade or so.
> 
> http://sunoano.name/ws/public_xhtml/scm.html#etckeeper

Thanks a lot. This is great. I had been looking for some tool like that for a 
while and had some failed attempts with SVN (failed with respect to the 
metadata).

Thanks for the helpful article and thanks for the pointer to the tool.

// Oliver


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org