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

Would it worth to have client-side properties in subversion?

From: Fernando P. Nájera Cano <tortoisesvn_at_fernandonajera.com>
Date: 2006-01-16 00:58:50 CET

Hi,

Just read the message in the users list about same-name-different-case
files [sndc files from now on]. I know this email I'm writting should
go to some subversion list, but I have never written there and I
prefer to know if my idea can be useful here among my friends :)

There are several problems that people want to solve/workaround, and I
think all of them already had been asked in this list:

* Client-side hooks, such as running something after commiting or
updating.

* Being able to ignore some files when exporting.

* Being able to checkout sndc files, via rename or ignore.

* and maybe more, I just don't remember.

I think all of them could be solved if svn libraries could honor some
properties, as they already do with svn:keywords, for example.

There would be two sets of properties. One would be
platform-independent (say 'svn:export-ignore') and other would be
platform-dependent (say 'svn-win:rename-as').

As you'll guess, I'm talking about: svn:export-ignore,
svn-win:rename-as, svn-win:cli-hook-post-commit,
svn-win:cli-hook-pre-commit, svn-win:cli-hook-pre-update,
svn-win:cli-hook-post-update.

And yes, again, I know this is something TSVN has nothing to do with,
but sdnc files *are* a real problem, specially if you cannot change
the name or renaming it has any other consecuences.

<talking-without-knowledge>

I think svn-win:rename-as could be easy for svn developers to
implement, providing code can know if running on Windows. It should be
something like "if svn-win:rename-as exists then copy temp file to
destfolder/new-name, else copy temp file to destfolder/same-name".
When commiting, it should do the opposite, and there it goes. AFAIK,
there is no way for TSVN to tweak this.

svn:export-ignore should add an 'if' at some point of the code, so I
think it couldn't be so hard to do.

Cli-hooks seem to be more difficult. There is a lot to say about them
(just one example: if a folder and a file have the property, which
comes first?). But I think - Stefan, don't get upset, I'm just
dreaming - that TSVN can do something 'lite' here. For example, if you
restrict hooks for folders, and determine a fixed rules of running
(say inner->outer), TSVN could honor them. Even if SVN libraries don't
do anything with those properties, TSVN could review the files and
folders updated/commited [I think the information already is in the
status dialog] and search for the properties, then execute them.

As for exports: even if there is no event TSVN can listen for each
file exported, when the export is done TSVN could crawl each
file/folder in the exported WC and look for svn:export-ignore, and if
found, delete the file/folder in the exported tere. I know, poor-man
solution, but at the end, user has what he wants.

</talking-without-knowledge>

I really think svn-win:rename-as should be implemented quite soon in
SVN because, whether svn developers like it or not, Windows have this
case-insensitive 'feature' and SVN should cope with it - better than
saying "sorry, don't use Windows anymore!". Cli-hooks would be a great
big point for TSVN if svn people don't want to implement them, and
maybe, if people find them useful, they eventually would write svn
developers: 'hey! I like the way TSVN let me interact locally with
commits/updates, why svn.exe can't?".

Please, forgive me, I'm tired and I don't really know what I'm
writting.

Best regards,

Fernando Nájera

-- 
avast! Antivirus: Mensaje saliente limpio.
Comprobado: 16/01/2006 0:59:06 - Base de datos: 0603-0, 15/01/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jan 16 00:59:37 2006

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.