[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Feature request: Vizualization of 'fsvs' properties.

From: mmm4m5m <mmm4m5m_at_gmail.com>
Date: Fri, 5 Sep 2008 01:48:04 -0700 (PDT)

Hi,

From my point of view, the problem is slightly different. Let me try
to explain:

if programmers use svn to version source files, administrators could
use fsvs to commit configuration files.

You could use svn to version and commit your linux installation or
part of it. Example directory '/etc'. Very easy you all config files
from '/etc' directory will be saved (backup) and will become under
version control (version control backup solution). Then you could easy
diff or revert any file. etc.

There are some negatives: - regular svn client save data inside '.svn'
directories - svn does not version meta data (modification time, mode,
owner, group. permissions) - when new program is installed, new config
files are created. Their status will be 'unversion files'

fsvs is svn client, trying to solve these negatives. fsvs is using svn
as backend.
There could be more. An example: consider two or more computers with
common programs, common config files. They could share single svn
repository.

Starting from svnhome (http://joey.kitenet.net/svnhome/), I found many
other projects/articles/mail lists:
svnhome, cvshome, etckeeper, git-home-history, vcs-home, etc.

I read a little, many people bother about meta data (permissions,
etc). There are some scripts like commit hook, or run script after
commit/update just to fix the meta data (permissions, etc). FSVS
handle it much better.

I sent email to one mail list, asking them if they hear about fsvs and
what they think. They start argue: which one is better svn or git.

> I mentinoned this before: what if Subversion wants to use the very same
> properties in the future...

And now about the current questions and doubts: Which one is first,
egg or chicken?

Do you think svn developers will annonce soon: 'lets make svn for
administrators and svn for backup... because svn for developers
(source) is very completed and there are no any bugs'?

Negative, I think it could be (maybe soon) especially if people have
chance to try it, if they find it useful and ask for it.

Apart of all above:

If svn decide to use the properties which are already used from fsvs:
1) fsvs could be changed
2) properties in existing 'fsvs' repositories could be very easy
changed

If you decide to show 'custom columns' inside 'tortoisesvn repo-
browser' screen, it could be completely not related to fsvs project.
They could be 'custom columns' and people could use them as they wish
(little like you have bug tracker URL and bug ID and special column in
'svn log' screen).

I do not want to continue this discussion. And I am not in position to
argue or to prove my self. Maybe Stefan arguments are strong enough
(for him), but my priorities and my point of view are different.

Kind regards,
Plamen.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: dev-help_at_tortoisesvn.tigris.org
Received on 2008-09-05 10:48:51 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.