memoarfaa / tortoisesvn Goto Github PK

For all log caches, the system shall poll the respective repositories for
new log info. Missing data is then fetched and written to the cache. The
goal is to make the log display instantaneous.

The following has to be implemented:

* the update interval shall be configurable.
  Default is 250 seconds, i.e. slightly below the default
  MaxHeadAge.
* if the access fails, the respective repository
  will not be contacted again for a pre-configured
  period of time. Default: 3600 seconds.
* the user shall be able to disable the auto-update per 
  repository (i.e. log cache file)
* at most 100 entries will be fetched per query
* HEAD lookup & cache update will be done on the common
  base folder of all cached changes
* caches that are currently used (i.e. locked) shall not
  be updated

May be implemented similar to or even as a part of TSVNCache.

in the branch/tag dialog, indicate somehow (additional column maybe?)
whether an external is already fixed to a specific revision.

The preface and introduction sections are rather long-winded and could be 
packed down into a single section. This would make space for section 1 to 
become the quick start guide (issue #12).

Unfortunately this will mean some churn in the text for translators, but 
hopefully it will be worth it.

http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=26730
43

I have lots of checkouts of different project and branches. It's great
that TortoiseSVN remembers all my from-locations in a dropdown, but
even nicer would be if it would remember the from locations that I
used for the working copy where I'm trying to merge into.

Currently when a patch is created, and saved to a file, TortoiseUDiff is
automatically opened to show the patch. 

This should also happen when the patch is saved to the clipboard. Or at
least add another checkbox which enables this.

In TortoiseMerge (and maybe some other places too) use Direct2D to draw the 
texts and other graphic stuff. Of course only where Direct2D is available.

Applications that use TortoiseProc should be able to get selected 
revisions/urls from the repository browser and log dialog.

1. App calls TortoiseProc.exe with new parameter "outFile" where revision 
numbers and/or urls will be saved.
2. User selects revision or url and clicks Ok.
3. Selected revisions are saved in file specified with "outFile".
4. App reads outFile

From the mailing list:

The Update to Revision dialog lets you do the equivalent of "svn up 
--set-depth", but as far as I can tell, there's no way to do the equivalent of 
"svn up --depth".  It would be great if the Update to Revision dialog had a 
"Set Depth" checkbox to specify whether the you're doing --depth or --set-depth.

The reason we need the "svn up --depth" functionality is because we need to be 
able to update the svn:mergeinfo property on the root folder without having to 
update the entire source tree, otherwise it's difficult to commit merges.  On a 
large project with many developers, it can take several minutes to update the 
entire source tree, and if any developer makes a commit somewhere in the source 
tree during your update, you still won't be able to commit your merge because 
the svn:mergeinfo property will be out of date again.

from
http://groups.google.com/group/tortoisesvn-dev/browse_thread/thread/7ac3f7760fa2
083b/cb30a3544a849978?pli=1

When the patch file is loaded you are presented to an empty TortoiseMerge
window, with a small "File patches" window that you need to interact with
to actually apply the patches.

- Here I would suggest to add two buttons to the "File patches" window:
"Patch all files" and (if a selection is made) "Patch selected files".
While these are available in the context menu, it is not really that
obvious that you have to right click somewhere before you can patch the files.

- Extend the names in the context menu from "Patch all" and "Patch
selected" to the more clear "Patch all files" and "Patch selected files".

- Maybe there would be possible to indicate in the "File patches" window
what file that is open in the TortoiseMerge-window. Perhaps by making that
file bold? 

Some machine generated files have overly long lines, e.g. xml files, sql
scripts.

TortoiseMerge should have an option to wrap those long lines but still be
able to show the diffs.

To determine:
* how to split the lines? Fixed length? Window border?
* split both views at the same length?

For the Show Log dialog, I think it would be nice to see some sort of
highlighting support for search terms. For example, if I search the word
“Bob”, that should highlight anything that matches, including but not
limited to:

 * User Names
 * Log Messages
 * Paths (in the bottom pane)

Basically, any location in the Show Log dialog where search terms are
applied, there should be some sort of highlight or other indicator that
makes it obvious where the exact location of the search term is.

Another alternative would be to gray out items in the file list at the
bottom for paths that did not match the search terms. This, however, could
create an ambiguity with the graying out that is already done for items or
paths that reference files outside of the directory where the show log was
invoked.

Problem:
Side-by-side installability of 32 and 64 bit TSVN can be helpful in some
situations, e.g. during TSVN development. However, there will be two
TSVNCache instances running and basically listening for the same file
change notifications. That might hurt performance.

Possible solution:
Teach 32bit TSVN to detect and use an already installed 64 bit TSVNCache.
Versions must match, though (at least 2 figures).

The log dialog has a pair of date pickers at the top which are used to
filter the log messages already downloaded. Whilst this is a valid use,
what most people expect them to do is to set the range of revisions to be
fetched from the server. That function is available in the Get Range
dialog, but only by entering the command-line format string, e.g. {2010-04-01}.

The Get Range dialog could be enhanced by adding a date picker to the start
and end boxes.

The main log dialog would be less confusing if the date-time pickers were
not shown by default, but maybe enabled from the drop down menu on the
search box, since that is where all other forms of filtering are done.

in BOOL CAboutDlg::OnInitDialog()
...
    SetTimer(ID_EFFECTTIMER, 40, NULL);
    SetTimer(ID_DROPTIMER, 300, NULL);
...
there should be KillTimer() call.

http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=26693
89

It would be a useful feature to have a 'right click option' to copy
the lock message when hovering over a locked file in the commit
dialog.

Our team members use the lock message to indicate what task they are
locking the file for. Usually this message is the same for all files
involved in a task, and most of the time just putting this task
description in the commit message is enough to keep track of what was
changed to the application (because of the way we define our tasks)

As the copy all info from this line menu item is already available we
do have a work around. Just copying full row content, pasting it and
doing the cleanup does the job, but the cleanup wouldn't be necessary
when the 'Copy lock message' option was available (only in case of a
locked file)

Does this feature request make sense for you?
Maybe the feature could be made more general, as in 'Copy this cell
value to clipboard' for every cell in the SVNStatusListCtrl component?
(I did have a look at the code, but I'm not capable of writing C to do
it myself, sorry)

add new properties like these:
tsvn:logtemplatecommit for commit dialogue,
tsvn:logtemplatebranch for the branch/tag dialogue,
tsvn:logtemplateimport for import dialogue,
and so on for all dialogues that require a log message.

If the property for the specific dialog is set, use that template. If it's not 
set, use the existing tsvn:logtemplate property instead.

http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=26726
06

Just an idea. All dialogs save their location and sizes.

What if the Repro Browser would also save the location of the divider
between the tree panel and the right panel?

That would save a mouse movement (to position the divider to give
the tree panel more space) each time the repro browser is opened.

In case a client side hook fails, we should have a way to override that and
commit anyway.

The reason I want this feature:
We use the checkyear.js script to check that all files have the correct
copyright year in the header. Problem is that if we commit a file that's
taken from an external source, that script complains and aborts the commit.
But we still need to commit those without changing the copyright information.
Right now I have to open regedt32.exe and rename the 'hooks' entry, then
restart the commit.

The main log dialog would be less confusing if the date-time pickers were
not shown by default, but maybe enabled from the drop down menu on the
search box, since that is where all other forms of filtering are done.

(See also issue #24)

Issue #10 implements new dialogs which handle specific properties better
than the current text-based approach.
These need to be documented.

The dialog to edit the bugtraq: properties maybe should be documented not
in the 'properties' chapter but in the chapter about issue tracker integration.

svn 1.7 has its own patching function.

Use that patch function in TortoiseMerge instead of our own custom one.
Of course this should be done in a way so we don't loose any features we
already have.

In work I am trying to use the by-author commit stats to work out who was
working on which project and when. It is not as easy as I had hoped, and
here’s why. Although the complete information for a project is available if
you use show-all in the log dialog, we restrict the number of data points
in the graph to give a sensible view, so for a project that lasts a couple
of years you get a very ‘smoothed’ graph showing that 300 commits were made
in Q2 of 2008, but not that it all took place in weeks 18, 19, and 24.

One way round this is to allow a pan and zoom on the time axis of the graph
so you can select a horizontal scale which shows the right level of detail
and use a horizontal scroll bar to traverse the (very) long graph.

A separate zoom control for height would be useful as well for pulling
detail out of low points on the graph.

Since creating a trunk/tags/branches structure within a repository is such
a common requirement, we should add a checkbox to the create repository
dialog to automate this on repo creation.

In the interests of keeping it simple no other UI options will be offered.
The structure will be trunk/tags/branches (English names). If you want
something different then you can do it the old way.

In the log dialog, show tooltips for bugtraq: links.

After a repository has been created, show a better dialog.

That dialog should have a button to create the default directory structure 
(trunk/branches/tags) and a button to directly start the repository browser.

And maybe an edit box with the repo file url so users can copy that url to the 
clipboard.

After setting up a local SVN server on my Linux desktop PC and checking out
via SSH to my Windows 7 desktop I came across errors on checkout that
turned out to be over files that contained colons in their names.

The error message was "The filename, directory name, or volume label syntax
is incorrect". Strictly a correct message but not very informative. It took
me quite a long time to work out what this meant. I am not the only person
to get stung by this error –
http://www.red-bean.com/pipermail/svnbook-dev/2006-October/002525.html.

I would like to make a feature request for two changes:

1) Update the documentation to include a section on what happens with
invalid characters / special characters (could not find any reference to
it). As far as I can see the TortoiseSVN help files don't even state the
level of support for accented characters etc. which is a non-obvious thing
for me. Something like "TortoiseSVN supports file names containing any
characters that your version of Windows supports...Windows specifically
disallows characters \/:*?"<>| in file names..." would be great, if my
assumptions are correct.

2) If at all possible in TortoiseSVN make the error message more helpful to
the user in this circumstance. "Error... file name of 'Hello:world.txt'
contains invalid character ':'" or similar would be great. Windows 7 tells
me it doesn't allow any of \/:*?"<>| in file names, so maybe TortoiseSVN
could specifically check for those ones?

See here for why:
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=26305
15

The import command from Subversion only takes one path (usually a folder)
which is then imported (also usually recursively). This leads to many users
importing files they don’t really want in version control.

Since import is usually the first command a first-time user has to do, we
should work around that Subversion limitation and provide an easier import
feature.

1. scan all files below the folder to import
2. show those files the same way we do in the commit dialog
3. let the user choose the files to import

then, when the user clicks on OK, we’d have to do:

1. checkout the URL where the user wants to import to over the selected
folder to import (SVN 1.5 can do that without generating an error).
2. SVN Add all the files (and folders) the user wants to import
3. Commit

When the repository browser starts up, we contact the repository to find
the repo root and get some other information.
During that time, the repo browser dialog is not responsive and that
operation can't be canceled.

We should maybe do that in a separate thread.

Implement the same feature as TMerge now has which marks all occurrences of a 
selected word.

While working on Gurtle I missed a way to test my changes.

Implement a small test tool that:
* loads the plugins
* has buttons to call every method of the interfaces
* customizable parameters to pass for the methods

TortoiseMerge should be able to ignore changes in code comments.

Of course, this is dependent on the code language.

Maybe only for single line comments like
//
#
'

and not for multi line comments like
/*
bla bla
*/

since that would require much more intensive parsing.

Currently the only coloring option in TortoiseBlame is "by age".
Add options to color by "author" and "revision".

Screenshots of the VisualSVN blame tool attached.

I am looking to add case sensitivity to TortoiseSVN.  I am a developer
looking to make a patch myself, unless it is found easier for someone else
to do this before I get the chance to.

Right now, I am having troubles getting it to compile using Visual Studio
2008 Pro w/ SP1.

But once I get through that trouble (and separate issue, if it comes down
to it), I would like to find what TortioseSVN is using to make new files
(CreateFile(), Windows API, for example) when checking out a new project.  

If it is using the STL to make files, then I assume I will need to look
into getting support into that for using FILE_FLAG_POSIX_SEMANTICS on file
creation.

Otherwise, if TortioseSVN does happen to be using the Windows API
CreateFile() directly, I would like to know where that is at in the project
(I have been searching, but only two days into learning this project).

Below is a two second program which creates two files of the same name, but
different case sensitivity (to prove that any version of windows nt
supports it).

[code]
// Don't include bloated MFC junk.
#define WIN32_LEAN_AND_MEAN

#include <windows.h>

int main()
{
  HANDLE hFile1 = CreateFile(L"MyTextFile.TxT",
                             GENERIC_WRITE | GENERIC_READ,
                             FILE_SHARE_READ, NULL, CREATE_ALWAYS,
                             FILE_ATTRIBUTE_NORMAL |
                             FILE_FLAG_POSIX_SEMANTICS,
                             NULL);

  if (hFile1 != INVALID_HANDLE_VALUE)
  {
    CloseHandle(hFile1);
  } // End If


  HANDLE hFile2 = CreateFile(L"mytextfile.txt",
                  GENERIC_WRITE | GENERIC_READ,
                  FILE_SHARE_READ, NULL, CREATE_ALWAYS,
                  FILE_ATTRIBUTE_NORMAL | FILE_FLAG_POSIX_SEMANTICS,
                  NULL);

  if (hFile2 != INVALID_HANDLE_VALUE)
  {
    CloseHandle(hFile2);
  } // End If

  return 0;
}  // End main() Function
[/code]

You may need to change registry key (WindowsXP Home/Pro) per article
http://support.microsoft.com/kb/817921.  I did this before checking whether
this change was required.

Attached is a screenshot of the result.  If anyone can point me to help
change TortioseSVN to work with case sensitive file names, at least for
myself, and so I can later submit a patch, I will be very grateful.

Please mark this as duplicate if it has already been considered (didn't
notice it when searching) :)

Hopefully Helpful,

TamusJRoyce

Background:
----------
In addition to the mere fact that a certain file has changed, 
it is useful to know how much it changed. Some aggregate information
over multiple files and / or revisions may be helpful as well.

Proposed Feature:
----------------

In the "Statistics" sub-dialog of the log dialog, a new page will
* show the change size for each file and folder modified in the
  given revision range
* show the (partial) sums for each parent folder
* works on "affected paths" only (to reduce the server load)

The data may be displayed in a tree grid.

For each changed file or folder, the following information shall
be shown:

* number of "changed lines" in format "+nnn/-mmm" for non-binary files
* number of "changed props" in format "+nnn/-mmm"
* final file size and delta from initial site in format "nnXB (+/-mmXB)"

Folder nodes with property changes will be displayed as a separate
row under the name "." . Otherwise, we would need to distinguish between
local and summary information.

Implementation:
--------------

The file sizes can be retrieved using "svn info" calls and the results
may be added to the log cache size they are immutable. All other 
information can be extracted from a single unified diff.


Restrictions:
------------
Not available if more than one revision range has been selected.

add a new project property "bugtraq:provideruuid64" for the x64 versions of
the plugins.

This is needed because the x64 version of TSVN can't use 32-bit versions of
the plugins, and vice-versa. Which means the plugins must use a different
uuid for their 32- and 64-bit versions, and TSVN must not load the wrong
plugin dll.

The branch/tag dialog doesn't have the issue tracker integration as the
commit dialog.

VisualSVN has different dialogs to set specific properties.
We should implement something similar.

Attached screenshots from VisualSVN.

People often ask for this feature:
The repository browser should be able to list all available repositories
which are shown in the webbrowser if the SVNParentPath directive is set.

The revision graph shows the log message in a tool tip when the mouse
pointer hovers over a node.

As an option, show the first part of the comment directly in the node
itself, as SyncroSVN does.
See attached screenshot.

Win7 introduced libraries, which basically are virtual containers for other
folders.

* allow the creation of a "Subversion" library for working copy folders
* create a custom library template and add buttons to the library header
bar for update, commit, CfM and log (we could add the buttons to e.g., the
"documents" or "general" library, but I don't like to mess with users
settings and those buttons really are only useful for working copies)

This requires a lot of new registry entries (i.e, the installer WiX files
need to be modified accordingly), new defines in our Win7.h file for all
the library functions, new icon(s) and of course a lot of testing.

Implement insertion, deletion, renaming and modification of svn:externals
in the repository browser. So, they not just look like (a special kind of)
folders but basically allow for the same operations as the latter.

We quite often get real newbie questions from people who are daunted by the 
docs and can’t get off the ground. Also for people who are evaluating RCS 
and just want to try things out without going through the whole learning 
process.

There are various tutorials and getting started guides floating around on 
the internet and in blogs, but they are not maintained. It would be better 
if we could produce our own.

In some ways it would be good to have a separate standalone file. But there 
are also advantages to making it part of the main TortoiseSVN docs:

* it will be a good starting point, and maybe make the docs less 
intimidating.
* having it separated means adjusting the translation scripts and another 
pot file for the translators to watch and work on.
* having it integrated means the quick start guide can forward-reference 
the full description in the same document.

The url of a node in the revision graph should be copyable to the clipboard
via a context menu entry or some other means.

All developers in our team just installed TortoiseSVN-1.6.10.19898 and we have 
the same problem after the first time installation: all the icons of the 
folders and files in repository were gone. To fix this issue, we tried to run 
the install program twice and chose “Repair” instead of “Install” for 
the second time and then the icons showed up. 

What's the link to the discussion about the problem on the mailing list?


What steps will reproduce the problem?
1.Install TortoiseSVN-1.6.10.19898 
2.All icons are gone.
3.Install the second time with repair, all icons are back.

What Windows version are you using?
Win&

Please provide any additional information below.

From the mailing list:
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=25097
16

in some use cases users dont have working directories (or dont know
exactly which working directory belongs to which branch) but need to
check a certain repository entry regularly. They can make links e.g. on
the desktop to the URL path, e.g. "svn://somerepository.com/repo1/prj2".

To make it easier to create such links, it would be great to drag the
URL (maybe an icon to the left side of the URL string) out of the repo
browser onto the desktop.

From the mailing list:
I have a request for a feature that I would consider useful. When selecting 
multiple revisions in the log viewer, you get a merged list of modified 
paths. What I would like in addition is a merged list of log entries (in the 
text field in the middle).

I would suggest this behaviour:
1. Any log message is changed so that it is terminated with exactly one 
newline. This may add or remove newlines.
2. If there are now two equal log messages, the newer one is discarded.
3. The messages are otherwise sorted by their age, oldest ones first.


http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=26606
88

In the repository browser, enhance copy and move operations, including
drag&drop to allow for:

* duplication of externals
* creating a "link", i.e. svn:external, to the folder source
* resolving the svn:external source, i.e. insert the actual
  content behind the source at the target location

The Post Update hook work only for the update command not with checkout 
and switch commands. I suggest three possible ways to solve this -
1. The post update hooks can be executed not only for update command but 
also for checkout and for switch ones.
2. Additional hook types can be added - checkout hooks and switch hooks.
3. The client hook interface can be extended in the way that every command 
can fire all types of hooks - Start, Pre and post for EVERY command - the 
most general solution, but the most complicated one of course.
The choice what way to select is up to you.

from
http://groups.google.com/group/tortoisesvn-dev/browse_thread/thread/7ac3f7760fa2
083b/cb30a3544a849978?pli=1


When you have selected "Apply patch...", a TortoiseMerge window opens with
a dialog titled "Select diff file...".
- I would suggest modifying the name of the TortoiseMerge window to "Apply
patch", or perhaps "Apply patch - TortoiseMerge" or similar. This will make
the Apply patch window easy to find in the windows task-bar.
- The title of the "Select diff file..."" dialog could maybe be a little
clearer by writing "Select patch file...". The command is called "Apply
patch", and the default file extension when creating a patch is .patch, so
I think it would make more sense.