On 9/30/05, Matthias Wächter <matthias.waechter@tttech.com> wrote:
> > [...] 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"?
Because: *every* build system produces files (the so called output).
Adding those automatically? I would get killed by our users!
> 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.
> > 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.
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.
> > 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.
> > [...]- 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.
No. Adding unversioned files is something completely different.
> > 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).
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.
What we do is:
- have *only* files under version control which are *not* generated.
- 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).
This avoids commits of generated files in between releases which are
really completely useless and also are a clear invitation for
conflicts.
> 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.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
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:21:22 2005