Stefan,
Stefan Küng schrieb:
> Because: *every* build system produces files (the so called output).
> Adding those automatically? I would get killed by our users!
Choose: You get killed by your users or get killed by me ;-)
No, I didn't mean you have to automatically add new files (but anyway,
you have to commit them to get into the repos, don't you?) but I meant
you have to treat new and deleted files the same way, but TSVN doesn't.
>>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.
> Please stay correct: TSVN does *not* automatically delete the files!
> It automatically *selects* missing files for deletion on the next
> commit.
Of course, the delete is done by the user, but TSVN, opposed to SVN CLI,
automatically selects the files for removal. Please, Stefan, at least
_try_ to get my point and don't force me to be verbose to debug level 100.
>>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.
> If you're working in a certified environment, then you simply *can't*
> pass all required tests with a deleted file. Because then, your build
> system would either build that file again, or your test system would
> catch that the file is missing and throw an error.
> And you *do* run tests before you commit, don't you? After all, you're
> working in a _certified_ environment.
I don't want to argue about certified environments. There are hundreds
of thousand ways and levels of certification and how such environments
could look like, please don't presume anything about _my_ special
environment. TSVN's task (as with any other source control system) is to
handle WC and repos properly and don't presume anything about a process,
testing, Makefiles etc. This is a flaw in TSVN in this aspect.
Just to answer your testing question: Usually, if you have a large
directory with a lot of files with similar functionality, you use
wildcard characters to specify dependencies. What if someone deletes one
of hundreds of test source files? One missing test case file will not
show up anywhere, and committing a whole directory overseeing this one
test case file can result in a serious situation. Source control
_should_ be your friend here because it forces you to specify additions
and deletions manually, TSVN does the latter automatically.
>>>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.
> Can you give me *one* (but real, existing) example where a program
> will delete files which are still required? If a file is really
> required, then your build/tests will fail if the file is missing. But
> if it's not required anymore, it can be removed.
Again, you presume way too much about my certification process. Let me
give you another example. What about README? Is it the dependency for
anything in your Makefile? Usually not. Would you like it be removed
from the repository if you accidentally deleted it from the WC? Usually
not. Do you like to review the list of files to commit to review whether
such a file accidentally slipped into? I do, everyone should, but it's
dangerous to allow deleted files to automatically get into the list of
removed files for commit. I want to rely on the revision control system
to only perform the actions I actually *requested*, like "Remove file
from repository", "Add file to repository", "Rename file in repository"
etc. - no automatism here.
>>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.
> No. Adding unversioned files is something completely different.
It's the same as deleting: It's changing the list of versioned files.
In my argumental position, removed and added files are same by nature
and should be treated the same (as in the CLI): A file that is part of
the repository but missing in WC is treated as a mistake, a missing file
(marked with '!' at "svn status"). A file that is part of the WC but not
yet in the repository is treated as a mistake as well, but an unknown
new file (marked with '?' at "svn status").
The only thing I request (or at least try to find sympathy for) is this
equivalence. I argued about generated files that are removed by "make
clean" and you told me that generated files are 'filetos non grata' in
the repository, but that is only one possible item. It's about all the
situations with deleted files, and all I ask for is a switch to enable
or disable this current automatism.
I do get your point that there are a lot of 'lazy' people that asked for
the feature that deleted files automatically are selected for removal
from the repository. I don't want to change their way of work. Anyone
who is happy with the current solution should be happy. But this
functionality should be _configurable_ as it might lead to serious
damage of the repository contents.
> You might not believe this, but I work here in an office where we need
> old versions stored someplace too. But I don't put them under version
> control.
Well, another process, another approach. I don't tell you how to do it,
why do you try to convince me that I have to accept automatic removal
selection for deleted files?
> What we do is:
> - have *only* files under version control which are *not* generated.
For a lot of projects this is the best way. The main cause for this is
repository space and lack of dependency tracking for generated files,
not philosophy, you know.
> - when we make a release, we create a tag for it in the repository
> - Then, a fresh checkout of that tag is made and build.
> - the binaries which we ship to customers are then zipped together (so
> it's only one file).
> - Drag that file from explorer to the repository browser on to the tag
> folder (this imports that zip file in to the repository).
[didn't know that works - nice functionality, though :-)]
> This avoids commits of generated files in between releases which are
> really completely useless and also are a clear invitation for
> conflicts.
One process, another one. Maybe sometimes I know all of them ;-)
>>So, bottom line: Do you consider a switch for enabling/disabling this
>>behavior or do you just laugh at my point?
> I won't laugh at your point. But I think I made it clear that you're
> not using version control right, and that you should rather change
> your use of TSVN/Subversion than have us implement something that
> would just encourage others to make the same bad decisions as you did.
It's sad to always talk about generated files. I shouldn't have thrown
this bone for you, you simply write as if you wouldn't get the point of
an accidentally deleted file in the WC, you rather like to teach me your
view of TSVN and version control as a whole.
Well, if your position is _that_ rock-solid, I ask you to remove the
feature "Delete files / folders from source control" from the
"TortoiseSVN" tab because it is a useless feature - remove it and tell
the people to simply delete the file since it will be committed anyway.
If the feature stays in the tool it misleads people in that they think
they have to delete the file using this TSVN function to get it into the
commit list.
- Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Oct 3 12:08:18 2005