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

Re: 1.7 feature list

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Wed, 12 Aug 2009 17:56:59 +0200

Stefan Küng <tortoisesvn_at_gmail.com> wrote:

> On 12.08.2009 12:40, Stefan Fuhrmann wrote:
> > Hi,
> >
> > this is the list of features that I intend
> > to implement within the 1.7 time frame
> > in no particular order.
> >
> > What gets actually implemented will
> > depend on release date, priority shifts
> > and so on, of course.
> >
> > * Repository browser
> > - handle externals seamlessly when
> > possible (some cases are THTH)
> > - allow manipulation of externals
> > - "Edit" for an c/o, lock, open, c/i cycle
> Is that really a good idea?

My company is using SVN for document management
(in particular: configuration management).
What occasional users would like is modify
the documents directly on the repository
(or be provided with that illusion). All
other operations, except for merge, are
already available in the repo browser.

Moreover, those people tend to be not tech-savvy
and the whole checkout ("just the right portion"),
update, lock, edit, check-in workflow is

Due to the unfortunate behavior of some DAV
clients, a simple Web-Folder access seems not
to be an option.

I'm not sure yet how the feature will work
in detail and whether it will turn out as
useful and stable as I would like it to.
But since this would be a mere addition,
we could still remove it from the 1.7.0 release.

Also, I certainly could come up with a number
of beta testers to assess the reliability.

> > - "Create Explorer link" to create an
> > LNK file that points to th specific
> > revision of that node. Variations
> > on that theme are conceivable,
> > e.g. drag'n'drop into explorer.
> I think I can do that - the SVNDataObject should be easily extended for
> this.


> > * Revision graph
> > - basic merge tracking similar to what
> > the log dialog does (mark merged and
> > yet-to-merge revisions)
> > - in 'group by branch' mode space efficiency:
> > show longer branches side-by-side
> > rather than one on top of the other
> > - auto-size box / column widths
> >
> > * Log dialog
> > - speed up display of larger (>1000)
> > revision lists
> The list control is already virtual, so the only speedup would be by
> changing the whole filtering?

Sizing the columns seems to be expensive.
There are a number of ways that we could
change that. Something along the lines of

- auto-size only upon request (double-click
  on separator in header)
- smallish default sizes
- heuristics to pick a good column width
  (max of default, header, top row in bold + margin)
- storing column widths

> > - speed up filtering
> that's not a bad idea :)

This one is actually coupled with speeding
up the initial display. I would like to
explain that in a separate post a couple of
days from now.

> > - filter by multiple criteria
> > (ex: '.ppt 2008 TSVN mylogin' to find
> > a presentation of mine made in 2008
> > on the topic of TSVN)
> should we build an index for this?
> Or simply extend the whole filter algo?

Entirely new implementation - also to be
explained by above mentioned post.

> > * Explorer context menu and / or log
> > - "Bisect" to automatically and semi-
> > automatically find offending revisions
> What do you mean by "offending revisions"? What would such a feature
> actually do?

GIT introduced this feature. The basic idea
is to specify a "good" (working) revision
and a "bad" (broken) revision plus some script.
Using bisection (based on length of actual
history not rev number arithmetics), the
first "bad" revision can be found.

The script is used to decide upon "good" or
"bad". For TSVN, I would like to support
fully automatic operation (user specifies
test and optional cleanup scripts etc.)
as well as guided operation where the user
has to press either to 'good' or 'bad' button.

> > * Property editor
> > - provide the user with some way to
> > optionally specify possible prop content
> > (no UI necessary)
> There's already the feature to load prop content from a file. What
> exactly would this feature do?

I want a way so specify that "svn:eol-style"
has on "native", "LF", "CR" and "CRLF" as
valid options. If the set of possible values
is known, the property list dialog should
show drop-down boxes in the right column.

Such feature would be particularly useful
for user-defined properties. Also, a regex
could be specified (to allow numbers only etc.).
In that case, a one-line edit box would be
available in the proplist dialog.

-- Stefan^2.


To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-12 17:57:34 CEST

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