On Thu, Nov 11, 2010 at 08:25, Richard M Willis <RichardW_at_pulsar-pm.com> wrote:
>> The thing is, if you have a file for which no
>> changes should be committed, then that file is not a > file that should be under version control in the
>> first place. End of story.
> I am not talking of a file "for which NO changes should be committed". I am talking of a file which has changed byte-wise, but not content-wise. If the file *has* changed (content-wise), then I want to check it in.
> Determining file equivalence soleley on the basis of strict byte-equality is near-sighted. In the same way that you don't test for C++ objects being equal byte-wise (you have an == operator and/or can have mutable members), I want to apply the same logic to files.
> What do people do in the case of, say, a MSWord .doc file, which seems to keep changing even though the file has only been "read" ?
> Come to think of it, how does the svn:eoln property deal with this: it must check a file out, do any necessary CRLF translation and then immediately see that it has changed. Not helpful.
> I could use a template and then copy on checkout, but then I'd have to (in the general case), write something to undo the changes and generate a canonical version of the file so that *that* can be changed against said template, at the point of checkin.
Now you're talking about Subversion being capable of understanding the
context of any arbitrary portion of any file, any format, binary or
text. That is impossible.
I haven't seen what you describe with Word, but I've seen it with
Excel. How can Subversion do a content-aware check when A) the content
changed isn't visible to the end-user and B) the file format isn't
fully documented/understood anywhere outside Microsoft?
My "solution" is to set svn:needs-lock on those binary files. When
they're read-only, Excel doesn't modify them when I just open them for
viewing. I only lock when I know I need to edit.
> How easy is to to write plugins for SVN or TSVN ?
There is no "plugin" architecture.
>> The real problem is that when you check out a
>> clean copy of your version controlled tree, the tool > chain won't run because it is not clever enough to
>> create its config files if they are not there.
> Sure it is, but it was developed in the days when people (on that type of development) didn't "do" SCM. Part of the reason for using SVN (or any SCM) is to retrofit SCM onto something that doesn't fit very well.
> The point is I don't want (T)SVN just to deliver me a version-controled tree; I want it to deliver me a project. Perhaps I should develop some front end to svn to make it work this way.
And Jeremy's point is that your project should be "clever" enough to
work out what it needs to function. Subversion doesn't know the
details of how application configuration files work, and IMHO it's
unreasonable to expect it to (you seem to want Subversion to know the
intimate details of how your applications work, which is not the job
of ANY VCS).
2 examples from my own projects:
1) Java Servlet/JSP web app, which at one point was deployed to a
dozen systems for various requirements. Within the project, I keep a
global configuration file (for anything that's universal across all
instances), an OS-specific config, and a machine-specific config. At
build/deploy time, the build/deploy script detects where it's running,
and selects the appropriate configuration files for that environment.
This works across 4 versions of Windows, plus MacOS & Linux, on about
a dozen servers.
2) ASP.NET web applications. Each can be deployed to one of 3 servers
(dev, test, production) plus the developer workstation. Each
environment has different connection strings, notification email
addresses, etc. We keep all of those configuration settings in the
application's source tree, and use Web Deployment Projects to make the
appropriate substitutions into web.config at the time we compile &
deploy the application.
Nowhere in these examples does Subversion have to have knowledge of
how the things it's storing actually work, because that's not the job
of a VCS.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-11-11 14:51:27 CET