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

Re: [TSVN] Proposed new feature in Tortoise

From: Molle Bestefich <molle.bestefich_at_gmail.com>
Date: 2005-04-19 11:20:28 CEST

Pierrik Vuilleumier wrote:
> My purpose is to keep track of documentation delivered by multiple companies
> within our satellite development project.
> As such, we don't have control over the nomenclature used to name the files
> and it happens often that names include version information.
> For example a file is called myfile-1.doc at issue 1 and myfile-2.doc at
> issue 2.

It would be useful for you to have the server rename the files using
fx. a regular expression, so that all files (belonging under a path
/docs/vendorx) gets "-n" before .doc stripped from their filename upon
commit, right?

New files would then be commited on top of the earlier version of the
file from the vendor correctly, although the vendor originally
provided the misc. versions of the same file with differing filenames.

Intuition tells me that the most obvious way to implement this would
be with a pre-commit hook script that:
 1. checks for a 'svn:strip-regex' option on the path being commited to,
 2. checks that the files being commited are in fact newer,
 3. strips the unwanted filename components (perhaps storing them for
later use in step #2) and
 4. gives back the new filenames to Subversion.

Unfortunately, I don't think that Subversion's pre-commit hook allows
you to change the filenames used by the client in the commit. And
doing so would probably also interfer with the current design of the
WC functionality..

So if you want to fix this, my guess is that you'll need to hack the
Subversion source. Or simply setup a repository for your vendor to
use ;-).

To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Apr 19 11:22:14 2005

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.