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

RE: RE: Managing duplicate and near duplicate files

From: Richard Yale <Richard.Yale_at_uk.linedata.com>
Date: Fri, 9 May 2008 13:15:37 +0100

Hi Keith

 

The files are text batch scripts to set up and run tests on regression
test environments.

Typically I would have a test pack with 10 sections which need to be
arranged as 10 subdirectories. Of the subdirectories 6, say, will
contain duplicate setup scripts plus various test scripts, 3 will
contain near duplicate setup scripts with a few extra lines or modified
lines to effect a slightly different setup and one might be quite
different. This is a legacy file set I've inherited the management of
and I find typically the setup files all have different names, e.g.
setup_future.txt, setup_option.txt despite being the same, but unifying
their names would be a big job.

Typically, e.g. to get the setup to work on the latest release of our
software, I might need to add a new section or modify a couple of
existing lines to the setup. I'd like to do this once then tell
Subversion to merge that with the related files. I don't want to need to
know which those related files are and I'd prefer not to maintain a
script that knows which files are related. If I add test section 11 I'd
need to maintain the script too.

I've told Subversion that the files are copies and modified copies so
I'm hoping I can tell Subversion to apply my change to each copy without
re-telling it which files are copies. If it makes things easier I could
create a master directory with the originals and then SVN copy them out
to their desired places and make my future changes to the master copy.

 

Thanks and regards,

Rich

 

 
 
Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851 VAT Reg No 778499447
 
________________________________
 

From: Keith Moore [mailto:Keith.Moore_at_securency.com.au]
Sent: 08 May 2008 23:52
To: 'users_at_subversion.tigris.org'
Subject: RE: Managing duplicate and near duplicate files

 

Hi Rich, what type of files are they? Can you give us some examples of
names and contents?

 

_________________________________________________________________

Keith Moore

 

-----Original Message-----
From: Richard Yale [mailto:Richard.Yale_at_uk.linedata.com]
Sent: Friday, 9 May 2008 1:23
To: users_at_subversion.tigris.org
Subject: Managing duplicate and near duplicate files

 

Hi I'm quite new to subversion so sorry for bad terminology, or a silly
question. I couldn't find my answer in the archive.

We've recently moved a file set over to subversion to manage changes to
and growth of this set. The set includes many duplicate and near
duplicate files (often with different names) across many directories
which I've identified and created SVN scripts to delete (near)duplicates
and SVN copy them back then restore the true file so that subversion
will know they were born from one original file and that they were
modified.

A change to one of these files usually needs to go into each of them so
my question is this: Is there a manageable way for me and other
contributors to change one of these files then roll out the change
across each duplicate and near duplicate file, if needed, without
needing to know which other files should take the change? I guess I
could write a script that will merge a change to a list of a file's
relations but that would be a lot of work to make reliable and would
need manual updating when a new duplicate file was made.

The file names and locations can't be changed for legacy reasons but I
could create a new directory with a "master" copy of these files if that
gets a simpler solution. The files are used from windows machines by the
way so I think that rules out any kind of symbolic link solution for the
exact duplicates.

 

Regards,

Rich

________________________________
Received on 2008-05-09 14:15:24 CEST

This is an archived mail posted to the Subversion Users mailing list.

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