On Wed, Jul 15, 2009 at 04:31:06PM -0400, Christopher Clarke wrote:
> > My understanding is that you'd like all other clients updating to rX
> > to remove the item from version control and add it to the ignore list,
> > but to also keep a copy of the item on disk for some reason.
> >
> > However, I don't understand what you would gain by preventing other
> > clients from the deleting the item from disk. Because if they aren't
> > allowed to delete the item, what happens if someone checks out a fresh
> > working copy as of rX? They will not get the item from version
> > control. But will they need the item to get your project to build?
> > If so, why isn't the item being generated as part of the build in
> > the first place?
>
> I see your point. The problem I am trying to solve is how to deal with
> files that have been added to the repository and need to exist in each
> working copy but that also need to be different in each working copy.
> The files should have been ignored from the start, but they weren't
> (because either I'm an idiot for adding them, or the situation changed
> since I did -- doesn't matter which).
>
> The way it works now, I have to email everyone detailed instructions for
> their particular OS and SVN client and, since I use SVN to manage
> development, staging and production servers, I have to carefully
> recreate these steps on each. In the case of production, this will
> increase downtime when I upgrade the site.
I have no idea about your particular setup, but it sounds like
a certain degree of automation outside of Subversion could help here.
You may be relying on Subversion to do a task it has not been designed
to do. Subversion versions data. It does not try to automate any other
task of a software life cycle, such as deployment of software on a
production server. People may be inclined to use Subversion for such
tasks since it has e.g. replication facilities in form of server<->working
copy updates, but that's not the intended use case. Subversion is usually
coupled with other tools which perform such tasks much better.
Do you think it would be possible to change your process to avoid
such problems in the future?
Or could you provide a script for your users which will do what's
required to revive the files, and instruct them to run this script
once after updating to the revision which causes the files to be
deleted? Instead of providing detailed instructions for each of
the user environments individually?
I understand that there is a problem with the way Subversion works
for you, but I don't think we should conclude that changing the way
Subversion works is the best solution to the problem without exploring
other possibilities first.
Stefan
Received on 2009-07-16 01:08:12 CEST