Hallo Stefan!
Stefan Küng schrieb:
> 1. Many people are lazy [...]
Oh, I like arguments stating that automation has to compensate laziness
talking of version control. :-)
> [...] and just delete files in explorer, without
> using the "remove" command from the context menu
Well, that's OK.
Then, why not propose that "People are lazy and just create files in
explorer, without using the "add" command from the context menu"?
But the former (deletion) is much more serious than the latter! I don't
get the point why the former must be automatically and the latter must
be manual.
> 2. People insisted that those entries are checked by default
OK, I can understand that there are applications where this behavior
might be A Good Thing, but why not make it configurable? Working in
certified environments doesn't allow such lazy-people-fault-propagation
automatism.
> 3. If a file is missing, you don't need it anymore [...]
You clearly presume a lot about specific working processes that IMHO
doesn't apply to _all_ processes.
> [...]- so why leave it
> in working copies of others? That just will lead to broken builds.
Deletion of a local file is one thing. But I cannot see why _automatic_
selection for removal from the repository is the logical consequence!
You can say the same for (3) about added files.
> The real question you should ask yourself: why do you have a
> *generated* file under version control???
Think about processes where you use version control not only for proving
who did what and to follow progress etc, but also for versioning the
builds. What if a customer reports an error using a *very old* release
of my product? Of course I have to keep the build as well to make sure
that I can reproduce the error using exactly the same version he has. In
"open source"-style (and most of commercial) applications the developer
usually answers to bug reports of old versions "Well, you use a _very_
old version. Download the current release and try to reproduce the
fault, then come back again and report it so we can replay it using the
current build. Thank you, bye." Good for such a project, and I like most
of them and get their point. But if you do business with TSVN (is this
allowed? ;-)) you have to assure that _you_ can replay the error in the
customer's environmental setup and not force him to upgrade just for
reporting an error.
Of course, you can take the built files and manually create some kind of
versioned directory keeping some released versions of this file. But -
heh! - we already have version control (usually for more than a reason),
why develop an old-style pseudo-versioning system in parallel in the
file system? The best place to keep versions of builds is, again, in a
repository, and in most cases it's A Good Thing to put/leave it in the
build directory.
Think of it. I would not keep the .o, .dvi, .ps intermediate/temporary
files in the repository, just the resulting output, and I would commit
it only if I want (this is process dependent, of course).
So, bottom line: Do you consider a switch for enabling/disabling this
behavior or do you just laugh at my point?
- Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Sep 30 14:07:21 2005