Re: Feature request: a way to exclude some extension from commit

On 12/05/07, Stefan Küng <tortoisesvn@gmail.com> wrote:
> First, thanks for your patch. But I have a few concerns about the concept.
>
> Roberto Paterlini wrote:
> > Usually when I do a commit I don't want to include some file like
> > *.csproj or *.config because they contains changes made from VS o from
> > the programmers that don't need to be released.
>
> *.csproj and *config files contain not just user data but affect the
> whole build process. If you miss committing such changes, you could
> break the build for others.
>
> I don't really see why you want to exclude those from commits regularly.
> I mean if you just want them excluded some times, you wouldn't need to
> add the exclude list.

That's exactly why you want this feature. If you exclude them always,
they would be unversioned. If you never exclude them, there's no issue
anyway.

> Maybe using a branch for your work would be a better approach for your
> situation?

I don't know about these particular extensions, but there are a lot of
IDEs out there which mix up project settings and workspace settings
(which files you have open in the IDE) in one file. And some change a
datestamp string in the project config file every time you build.

For a stable project where you are mostly tweaking existing files
rather than adding new ones, this would be helpful, but of course it
is also dangerous. IDEs that do that are dangerous anyway because they
push you into a habit of unchecking the project config file.

There's a similar danger in that if you add files to project and
forget to svn->add them, they come up as unversioned in the commit
dialog, but unchecked by default. And occasionally a file is missed.
With a code project you usually notice that when someone else tries to
build, but for a web project it might be an error page which is only
referenced when a very rare error occurs. There's no way to protect
against that sort of omission. At least with this feature you use it
at your own risk.

[snip details of patch]

> But I'm not even sure we should really do this. Having files excluded
> from a commit by default is a bad idea, because it leads to not-so-good
> working style. And once that's implemented, people will start excluding
> other stuff which shouldn't be versioned in the first place.
> And we'll get a lot of "BUG:!!!" reports every time they try to commit a
> removed folder. Because that's only possible with a recursive commit,
> which means *everything* will have to be committed then.

The logic will have to be more sophisticated and detect a deleted
parent folder. In that case it makes no sense at all to exclude the
file.

Should this be a client global setting, a client per-WC setting or a
project property? Making this global sounds unsafe. Imposing it on all
project users sounds potentially unsafe.

You could make it slightly safer by marking such excluded files in red
OSLT in the commit dialog, so it is obvious when this is happening.

Simon

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org