[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 Küng <tortoisesvn_at_gmail.com>
Date: Wed, 12 Aug 2009 19:21:20 +0200

On 12.08.2009 17:56, Stefan Fuhrmann wrote:
> 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
> cumbersome.
> 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.

Well, if you get this working in a way your people will accept it, then
of course we should keep this in 1.7.

>>> * 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

Or, just resize the colums to the visible rows.
I just committed a change in r16908 which should speed up this part a lot.

>>> * 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.

So "working" or "good" means a commit that is tested, while "bad" is one
that hasn't been tested yet. A bad revision can then be marked as good
as soon as it was tested.
Or am I completely wrong in my understanding of this feature?

>>> * 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.



   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-12 19:21:38 CEST

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