Login | Register
My pages Projects Community openCollabNet

Discussions > dev > discussion of fsvs setup in common binary packages

fsvs
Discussion topic

Hide all messages in topic

All messages in topic

Re: discussion of fsvs setup in common binary packages

Author pmarek
Full name P.Marek
Date 2010-08-31 23:49:30 PDT
Message Hello Gunnar!

>>> But the work begins if files needs to be sorted out because of
>>> privacy or bloating the repo etc. I think fsvs behavior can, because of its
>>> clueness and different use case, be different in that area. Comparing to svn the
>>> fsvs ignore list is also more centric then some sporadic propsets containing
>>> ignore rules.
>>
>>> I am also more for an option that changes the behaviour of "fsvs ignore".
>> "fsvs ignore" is the wrong place - that's for editing the patterns.
>>
>>> What about something like "sync-with-ignore" defaulting to false? Would it be
>>> necessary or even suffice to run a "sync-repos"?
>> As an option which is used on "commit" it's ok.
>
> For files that are already in version control the "fsvs commit" is for sure a
> good place. But what about the files that weren't commited yet und you want to
> get rid from "fsvs st"?
Well, this option should just control what changes are detected for files ...

So, if you look into ops__update_single_entry(), there the full path is already taken
via
    STOPIF( ops__build_path(&fullpath, sts), NULL);

If the option is set, you can just test the patterns and set the entry to FS_REMOVED, if
necessary ...



> My intention is to trigger the add/unversion operations somehow when the ignore
> list is changed via "fsvs ignore load/prepend/append/at=". Where do you think
> the storm breaks loose in the teacup?
The problem is that it's not stored that an entry is removed - that is found (by getting
ENOENT on lstat()) on the next invocation of "status", "commit", or whatever.

So there isn't really a list to change ...
And BTW you'd have to send the "unlink" events to the repository, too. So just removing
from the list of known files isn't enough.


>> I'm sorry, I seem to have caused confusion with my remark about "sync-repos".
>> I meant that there's already a command starting with the letters "sync", and because
>> FSVS accepts abbreviations a new command like "sync-with-ignore" could wreck somebody
>> trying to use "sync-repos".
>> (Although, with one more thought, someone who does "sync-repos" must not care about
>> his
>> WC list anyway.)
>
> Sorry, to mix-up things with that question. I did a quick test for myself now
> and resulting did not care about ignore list changes.
As long as the confusion is resolved ...


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: discussion of fsvs setup in common binary packages

Author tekknokra
Full name Gunnar Thielebein
Date 2010-08-31 09:15:52 PDT
Message On 31/08/10 17:10, P.Marek wrote:
> Hello Gunnar!
>
>> But the work begins if files needs to be sorted out because of
>> privacy or bloating the repo etc. I think fsvs behavior can, because of its
>> clueness and different use case, be different in that area. Comparing to svn the
>> fsvs ignore list is also more centric then some sporadic propsets containing
>> ignore rules.
>
>> I am also more for an option that changes the behaviour of "fsvs ignore".
> "fsvs ignore" is the wrong place - that's for editing the patterns.
>
>> What about something like "sync-with-ignore" defaulting to false? Would it be
>> necessary or even suffice to run a "sync-repos"?
> As an option which is used on "commit" it's ok.

For files that are already in version control the "fsvs commit" is for sure a
good place. But what about the files that weren't commited yet und you want to
get rid from "fsvs st"?

My intention is to trigger the add/unversion operations somehow when the ignore
list is changed via "fsvs ignore load/prepend/append/at=". Where do you think
the storm breaks loose in the teacup?

>
> "sync-repos" is of course not needed - only the filenames have to be checked against the
> filelist, and get added/unversioned as necessary.
>
> Or it could be used with "add" or "unversion" ...
>
>
> I'm sorry, I seem to have caused confusion with my remark about "sync-repos".
> I meant that there's already a command starting with the letters "sync", and because
> FSVS accepts abbreviations a new command like "sync-with-ignore" could wreck somebody
> trying to use "sync-repos".
> (Although, with one more thought, someone who does "sync-repos" must not care about his
> WC list anyway.)

Sorry, to mix-up things with that question. I did a quick test for myself now
and resulting did not care about ignore list changes.

Best,
Gunnar

>
>
> Regards,
>
> Phil
>

Re: discussion of fsvs setup in common binary packages

Author pmarek
Full name P.Marek
Date 2010-08-31 08:10:20 PDT
Message Hello Gunnar!

> But the work begins if files needs to be sorted out because of
> privacy or bloating the repo etc. I think fsvs behavior can, because of its
> clueness and different use case, be different in that area. Comparing to svn the
> fsvs ignore list is also more centric then some sporadic propsets containing
> ignore rules.

> I am also more for an option that changes the behaviour of "fsvs ignore".
"fsvs ignore" is the wrong place - that's for editing the patterns.

> What about something like "sync-with-ignore" defaulting to false? Would it be
> necessary or even suffice to run a "sync-repos"?
As an option which is used on "commit" it's ok.

"sync-repos" is of course not needed - only the filenames have to be checked against the
filelist, and get added/unversioned as necessary.

Or it could be used with "add" or "unversion" ...


I'm sorry, I seem to have caused confusion with my remark about "sync-repos".
I meant that there's already a command starting with the letters "sync", and because
FSVS accepts abbreviations a new command like "sync-with-ignore" could wreck somebody
trying to use "sync-repos".
(Although, with one more thought, someone who does "sync-repos" must not care about his
WC list anyway.)


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: discussion of fsvs setup in common binary packages

Author tekknokra
Full name Gunnar Thielebein
Date 2010-08-31 07:06:50 PDT
Message On 31/08/10 15:45, Philipp Marek wrote:
> Hello Gunnar!
>
>> Regarding enhancements I stumbled about an issue I noted some time ago with
>> ignore list behavior.
>> When new filter rules are applied to (or remove from) ignore list you still need
>> to add/unversion appropriate files manually.
> Well, it's the behaviour of subversion and git (and, IIRC, mercurial, etc. too), that an
> ignore list is used for detecting *which files should be versioned*.
>
> But it may not change the list of files that are already known, kept and stored.
>
>
> The basic idea was that the patterns are used for removing noise from "status" display -
> ie entries that are not versioned.
> "fsvs add" should have priority, so that I can always define exceptions to the rules.
>

I fully agree. But the work begins if files needs to be sorted out because of
privacy or bloating the repo etc. I think fsvs behavior can, because of its
clueness and different use case, be different in that area. Comparing to svn the
fsvs ignore list is also more centric then some sporadic propsets containing
ignore rules.

>
>> How hard would it be to implement some enhancement to run add/unversion
>> internally when ignore list is modified and will that break the philosophy
>> behind ignore list? I'd admit a sense to keep add/unversion for someone but the
>> disadvantage is that you loose an overview of the filtered files. Thats what IMO
>> the ignore list should also be used for. What is your point on this?
> Well, I could certainly imagine a command that synchronizes the filelist against the
> ignore patterns.
>
> Or perhaps an option for commit; but I think the extra command would be better.
> (If you make it an option, you could set it in your config - that would suit your kind
> of work better.)
>
>
> How about "filelist-sync"? No, too general.
> Hmmm, "sync" and "ignore" as prefixes are already well-established ... so it should be
> something different.

I am also more for an option that changes the behaviour of "fsvs ignore".
What about something like "sync-with-ignore" defaulting to false? Would it be
necessary or even suffice to run a "sync-repos"?

>
>
> Regards,
>
> Phil
>

Re: discussion of fsvs setup in common binary packages

Author pmarek
Full name P.Marek
Date 2010-08-31 06:45:25 PDT
Message Hello Gunnar!

> Regarding enhancements I stumbled about an issue I noted some time ago with
> ignore list behavior.
> When new filter rules are applied to (or remove from) ignore list you still need
> to add/unversion appropriate files manually.
Well, it's the behaviour of subversion and git (and, IIRC, mercurial, etc. too), that an
ignore list is used for detecting *which files should be versioned*.

But it may not change the list of files that are already known, kept and stored.


The basic idea was that the patterns are used for removing noise from "status" display -
ie entries that are not versioned.
"fsvs add" should have priority, so that I can always define exceptions to the rules.


> How hard would it be to implement some enhancement to run add/unversion
> internally when ignore list is modified and will that break the philosophy
> behind ignore list? I'd admit a sense to keep add/unversion for someone but the
> disadvantage is that you loose an overview of the filtered files. Thats what IMO
> the ignore list should also be used for. What is your point on this?
Well, I could certainly imagine a command that synchronizes the filelist against the
ignore patterns.

Or perhaps an option for commit; but I think the extra command would be better.
(If you make it an option, you could set it in your config - that would suit your kind
of work better.)


How about "filelist-sync"? No, too general.
Hmmm, "sync" and "ignore" as prefixes are already well-established ... so it should be
something different.


Regards,

Phil

--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

Re: discussion of fsvs setup in common binary packages

Author tekknokra
Full name Gunnar Thielebein
Date 2010-08-31 05:28:43 PDT
Message Hi,

Regarding enhancements I stumbled about an issue I noted some time ago with
ignore list behavior.
When new filter rules are applied to (or remove from) ignore list you still need
to add/unversion appropriate files manually.
How hard would it be to implement some enhancement to run add/unversion
internally when ignore list is modified and will that break the philosophy
behind ignore list? I'd admit a sense to keep add/unversion for someone but the
disadvantage is that you loose an overview of the filtered files. Thats what IMO
the ignore list should also be used for. What is your point on this?

Re: discussion of fsvs setup in common binary packages

Author pmarek
Full name P.Marek
Date 2010-07-22 08:10:04 PDT
Message Hello Gunnar!

First of all, the easy question:
> Also, if you have some fsvs config files that could be
> useful for others, I would appreciate to collect them
> and, with Phils
> approval, add them to the repository.
Gunnar,
you're an official (co-)developer.
You've got commit rights, and for a reason.

Although I reserve a right to revert changes (or at least bitch about them on the
mailing lists ;-) you're welcome with any help.

BTW, I'd appreciate that too.



> There are a huge count of usage scenarios possible with
> fsvs because of
> its flexibility.
> But as flexibility means also complexity I see a reason
> to give enduser
> the posibility of some easy start. Best way I see is
> to start within the
> packages available for different distributions/os'es.
Of course.
How about presenting a few ways to configure FSVS on (first-time) installation, so that
the users can choose from a few common szenarious?

> A big hit would be if other package maintainers would
> help to extend
> this to their distribution/os specific requirements.
> For example, where
> are looking for a way to add router configurations to
> the repository...
>
> Also if other common usage scenarios or best practice
> of fsvs could be
> implemented in package setup I think this is the
> correct place to
> discuss them.
Well, if we got a few changes for that I'd be willing to provide a 1.2.3 release.


> I am also very interested where you see the current
> glitches in getting
> fsvs running.
That's something that would be interesting to me, too.
Of course I'm not inpartial ... but from the silence on the
mailing lists I'd assume that either FSVS usage is not growing, or that FSVS is so easy
to use that for most people it "just works".

But I'd like to get hints what could get enhanced ...
Even if it's far-fetched - then I would simply add that to my (existing) FSVS-2 TODO list.


Regards,

Phil


--
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

discussion of fsvs setup in common binary packages

Author tekknokra
Full name Gunnar Thielebein
Date 2010-07-22 04:05:48 PDT
Message Hi all,

I want to start a discussion on how fsvs can be handled and therefore
eased for endusers within the distribution packages available.

There are a huge count of usage scenarios possible with fsvs because of
its flexibility.
But as flexibility means also complexity I see a reason to give enduser
the posibility of some easy start. Best way I see is to start within the
packages available for different distributions/os'es.

My customer uses fsvs for configuration management and is planning now a
huge rollout on client servers to fetch configuration file (/etc) into a
single/seperate repositories. As he uses Debian/Ubuntu I started with
introducing some fsvs setup tasks (dpkg-reconfigure) in the package itself.

That includes (and is going to include):

  - setup the repository working copy, that is in our case always / (root)
  - setup the repository url; we use only one url at the moment for
simplicity
  - setup a basic ignore rules set
  - setup an fsvs apt hook that triggers fsvs on apt install / upgrade
process
  - setup an fsvs cron job which sends notification on changes that are
not checked in

What i want is to define some standards regarding the specified usecase
like a common ignore ruleset, cron job, and pkg hooks that are also
adaptable to other distributions os'ses like Fedora, Solaris, OSX, Fink,
OpenWRT...

In the fsvs repository at:

http://fsvs.tigris.o​rg/source/browse/fsv​s/branches/fsvs-1.2.​x/fsvs/example/

there's already a directory hierarchy "debian/" that contains example
setup files for configuration management and ssl setup in enterprise
environments. They get used in the Debian/Ubuntu package.

A big hit would be if other package maintainers would help to extend
this to their distribution/os specific requirements. For example, where
are looking for a way to add router configurations to the repository...

Also if other common usage scenarios or best practice of fsvs could be
implemented in package setup I think this is the correct place to
discuss them.

I am also very interested where you see the current glitches in getting
fsvs running. Also, if you have some fsvs config files that could be
useful for others, I would appreciate to collect them and, with Phils
approval, add them to the repository.

Best,
Gunnar
Messages per page: