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

Re: [Subclipse-users] Bug/Issue: Subclipse marks folders for outbound changes when changes are made to deeply nested ignored files

From: Richard Fairthorne <richard.fairthorne_at_gmail.com>
Date: Wed, 9 Apr 2008 22:04:48 -0400

After playing with this a bit more, it might be a mild usability issue. I am
used to tortiose SVN on windows, and recently switched to Centos X86_64
which ruled out tortiose. There are two major behavior differences.

1) Tortiose optionally, and by default, includes unversioned files in the
commit checklist, but leaves them unchecked. Checking them adds and commits
them. Because of this behavior, you can easily see if there are new files
that need to be added, simply by trying to commit your whole source tree.

2) Tortiose does not highlight a directory as having changed if unversioned
files appear. It simply ignores them except when you try to commit a
directory.

As far as behavior #2, I think that either the Tortiose or the Subclipse
behavior can be easily justified. On the other hand, I think that *if*
subclipse is going to highlight an unversioned file change (indicating
something to do or commit) that listing the unversioned-unignored files in
the commit dialog (unchecked) would drastically improve usability by making
it obvious to the user why the directories are highlighted in red.

As it stands, I took about 5-6 minutes looking through a directory listing
by hand for a file which had a different icon than the others, in order to
figure out what I needed to do to resolve the "red directory".

I send this only in hopes that it is helpful to someone. Perhaps I should
rephrase this and file it as a feature reaquest tomorrow?

- Rich

2008/4/9 Richard Fairthorne <richard.fairthorne_at_gmail.com>:

> Lucky for everyone, it turns out I am an idiot. I found a non-ignored file
> that was lying around.
>
> I will be taking a giant dose of RTFM and going back to production now.
>
> - Rich
>
> 2008/4/9 Mark Phippard <markphip_at_gmail.com>:
>
> On Wed, Apr 9, 2008 at 8:02 PM, Richard Fairthorne
> > <richard.fairthorne_at_gmail.com> wrote:
> > > I believe that Subclipse wrongly marks folders for outbound changes
> > when
> > > changes are made to deeply nested files marked for svn:ignore. I feel
> > that
> > > this behavior is a bug. It can be tested thusly:
> > >
> > > In a controlled project, create a directory or any number of levels of
> > > directories.
> > > In the deepest directory create a file.
> > > Add the file to SVN:ignore
> > > Commit the project.
> > > Change the file.
> > > Make sure that "Compute deep outgoing state for folders" is enabled.
> > >
> > > In a default install, your top level folder will appear red
> > (indicating
> > > outgoing changes). Attempting to commit those changes will result in
> > nothing
> > > being committed, as there are no changes to controlled files.
> > >
> > > Does anyone have comments before I file a bug report?
> >
> > The svn:ignore property can only be set on folders. So when you ask
> > to ignore a file, what has to happen is the svn:ignore property of the
> > parent folder is added/modified to include the pattern you tell it to.
> > If this folder, and any of its parents are not currently versioned,
> > then they all have to be svn add'ed to SVN so that a property can be
> > set on them. It sounds like that is what is happening, although they
> > should show up in the commit dialog.
> >
> > Try it with the 1.3.x development releases and include screenshots if
> > it still seems like a problem.
> >
> > --
> > Thanks
> >
> > Mark Phippard
> > http://markphip.blogspot.com/
> >
>
>
>
> --
> http://www.obstaclesgone.com
>
> Richard Fairthorne
> c: 647-887-3876
> h: 416-203-6687
>

-- 
http://www.obstaclesgone.com
Richard Fairthorne
c: 647-887-3876
h: 416-203-6687
Received on 2008-04-10 04:05:04 CEST

This is an archived mail posted to the Subclipse Users mailing list.

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