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

Re: [TSVN] commit of missing files automatically selects removal

From: Matthias Wächter <matthias.waechter_at_tttech.com>
Date: 2005-10-03 16:49:49 CEST

Stefan,

[moved ahead]:
> Let me explain:
> A build process usually creates a *lot* of files. You definitely don't
> want all those files added to version control automatically.
> A build process usually does *not* delete files. At the very least,
> not important files. And you might not believe this, but if it does,
> then I'd say that build process is broken. And it's not TSVN's job to
> work around a broken build process.

I'd like to drop the discussion about versioning binaries from the main
topic "automatic selection for removal after deletion".

Versioned binaries were only _one_ possible situation where automatic
removal of deleted/missing files is annoying.

Stefan Küng schrieb:
> Hmmm - killed by many or just by one...
> I choose one!

"Puff!" ;-)

>>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.
> Sorry, slight correction: the CL client *does* automatically delete
> missing files on commit! So TSVN is just consistent.

with SVN 1.1.2 and SVN 1.2.3 it definitely doesn't, it only commits
files that were treated with svn or tsvn. What makes you think the CL
has the described behavior?

>>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
> But usually, a build step doesn't remove the README file.

No, but an accidental operation. An accidental removal (or rename) in
explorer is way more probable than an accidental selection of
"TortoiseSVN -> Delete" or the execution of "svn remove".

>>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
> As mentioned above: the CLI treats them differently too.
> And they're definitely not the same by nature.

I can agree with the build process, but do not agree with anything else.
I use (T)SVN not only for building stuff, I use it for developing as
well :-) And _this_ is where such mistakes happen, of course not
necessarily at the build process (even though one does development and
build within the same checkout).

>>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").
> You're assuming a lot here. What makes you think that "!" and "?" are mistakes?

What the VC program (among a lot others) should do is to notify
inconsistency between the repos and the WC, more precisely, between the
repos+add/remove and the WC.

You have three levels:

1. The repository - what is here is agreed and committed
2. The .svn stuff - what is here is the repos+add/remove.
3. The WC - what is here is only files, repos+add/remove and
create/delete as well as edit.

the tool's job on "commit" is to check for consistency between 2 and 3
for the given file list (no edit information) and to bring 1 in sync
with 3 (including edits). A change in 3 (create/delete) requires a call
of the VC software, for example "svn remove", to bring 2 in sync with 3.

TSVN does the latter automatically for removed files which contradicts
the first part of "commit" I noticed.

> We have a policy here in this project: no more options! The settings
> dialog already is crowded with many, many options. [...]

Hmmm. I think I don't have to expain TSVN's settings dialog to you, but
I think that there is at least space in the 'General' tab for a setting
related to this topic.

[ ] Automatically select deleted files for removal from repository

(defaults to checked)

>>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.
>
>
> Have you ever tried to remove a folder without using that command? Try
> it! If you then still think that this is a useless feature, we can
> discuss this again.

Well, one point for you, but then change it to "Delete folders from
source control" and don't show it for a single file.

Maybe the following aspects are cousins within the world of VC:

* allow commit/update only for complete directories (no mixed revs)
* conflict/merge not only for the context within a file but for whole
files and/or groups of files
* ignore conflicts at all (commit/update overwrites whatever lies in the
repos/WC)
* automatically add/remove created/deleted files and directories
(perfect commit)

I think we'll see svn:xxx properties in the future for them, some of
them might remain UI options, others might be repos-enforced.

- 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 16:48:36 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.

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