console-helpers / svn-buddy Goto Github PK

Add boolean config setting type, that would:

• accept true or false
• use choosing dialog, not interactive editor for value changing

When listing revisions add new column Merged Via, that would list comma-separated list of revisions where this revision was merged to anywhere.

During log parsing determine change of svn:mergeinfo property of revision to find revisions that were merged by each merge commit. Then create reverse index that would have revision as key and as value array of related merge commits.

Rename --limit option to --max-count with -n short version.

This change tries to unify option names with git log command.

Add --merged and --not-merged options to allow filtering revision that are already merged somewhere or not merged at all.

The detection is made purely by the merge commits. This results in bug, that revisions that were merged indirectly (e.g. by copying /trunk over to the /tags/stable) will be considered non merged.

Related to #23, where --merged-by option is added.

Due SVN 1.7+ mixed revision working copy merge protection (see http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html) the user is prompted to do svn update after each revision gets merged.

When the mixed revision working copy is detected, then run svn update without user confirmation.

Maybe don't ever ask confirmation for svn update.

Add "log.merge-conflict-regexps" option, that would have multi-line value. Each line would be regexp relative to working copy.

Example:

#composer\.lock$#
#project_upgrades\.sql$#
#*_config\.php$#

In the log command output add new column called M.O. that would:

• look at changed files in given revision
• count files, that matched log.merge-conflict-regexps option
• show number of matched files (don't show 0)
• highlight matched files when --details option is used

Depends on #3

When new --message (shortcut -m) is used, then it will denote commit message, that should prevent automatic message generation or interactive editor opening for it entry.

The commit confirmation can still be asked just in case.

The commit message is generated automatically (user can still change it) for cases, when committing merge result. In there each merged revision is merged in rXXXX format (e.g. r23343). This default format for mentioning revisions inside Subversion.

If such commit is imported into Phabricator (see http://phabricator.org/) then revision doesn't become a link to corresponding commit because Phabricator expects revision links to look like rABC23343, where ABC is repository callsign under which that commit was imported.

Propose to:

1. create the config setting called commit.revision_format of choice type with following options:
   • Subversion (e.g. r12345) - default
   • Phabricator (e.g. rABC12345)
2. when for given working copy the Subversion format is chosen, then do all as now
3. when for given working copy the Phabricator format is chosen, then:
   • look for .arcconfig file in the working copy root
   • if not found throw an exception
   • if found, but repository.callsign key isn't found then throw an exception
   • if found then use it's value for revision link building

The config command would allow to configure per working copy settings (e.g. default merge-source-url for working copies where it can't be detected).

• svn-buddy.phar config <path> - list all options for given path
• svn-buddy.phar config <path> option-name - shows value for given option at given path
• svn-buddy.phar config <path> option-name option value - sets given value for given option at given path
• svn-buddy.phar config <path> option-name option -e - opens interactive editor (preloaded with current option value) for setting value for given option at given path

The <path> defaults to current folder and must be a working copy.

If --global option is set, then path-wide (applies to all paths as default, when not specified by user) option is set.

The AbstractCommand::getConfigOption($name) must be added, that will:

• use $this->getName() to get command name (ensure, that for aliased command original command name is used)
• look for working-copy specific option for that name
• if found, then return it's value
• if not found return value of global config setting with that name

The value of merge.source-url setting needs to be validated:

• to be on same SVN server as working copy into which merge occurs
• to be an existing folder (not file) on that repository

New options:

• --merges - will list only merge commits
• --no-merges - will list only non-merge commits

Plan:

1. add RevisionLog::merges property (array), where all revisions, that change svn:mergeinfo property would be added
2. when --merges option is specified, then from path-filtered log records only leave ones from RevisionLog::merges property
3. when --no-merges option is specified, then from path-filtered log records remove ones from RevisionLog::merges property

Blocked by #19 , because will increment cache version.

Current RevisionLog does all sort of things with revision data and it's all mixed into same class. This is nightmare to test properly especially in complex scenarios.

Plan:

1. create the AbstractRevisionLogPlugin class (or maybe interface) with following methods:
   • parse(\SimpleXMLElement $log_entries) - parse log entries
   • find(array $criteria) - returns revisions matching all of given $criteria (criterion format isn't predetermined)
   • getName() - returns unique plugin name
   • setFromCache(array $plugin_cache) - initializes plugin using this cache
   • getToCache() - returns cacheable info
2. create plugins, that implement current tasks (see below)
3. add RevisionLog::find($plugin_name, array $criteria) method, that would forward call to corresponding plugin

Plugins that represent current functionality:

1. PathsRevisionLogPlugin:
   • stores paths, affected by each revision
   • stores reverse path-to-revisions index
   • allows to find revisions affecting given paths
   • will have paths name
2. BugsRevisionLogPlugin:
   • requires LogMessageParser instance to operate
   • stores bugs, found in log message of each revision
   • stores reverse bug-to-revisions index
   • allows to find revisions associated with given bugs
   • will have bugs name

This way RevisionLog now would perform only these:

• query revision info from database
• store basic info only (author, date, log message)
• addPlugin(AbstractRevisionLogPlugin $plugin) method
• let plugins parse/store needed info
• can have sugar, like shortcut methods for quick invocation of needed plugins

Blocked by #19
Related to #20

Right now the revision(-s) form is used instead of revision or revisions because it was faster to implement at the time.

Correct way is to:

• create method, that would accept:
  • number
  • singular form
  • plural form
• call that method to return proper text

The merge command is handling classic merge strategy, where specified revisions. Sometimes however another approach seems more appropriate - releasing.

Concepts:

• source path - obtained from --release-source option (works the same as --merge-source for merge command)
• target path - repository path from working copy, where svn-buddy.phar release command was executed

The workflow:

1. user executes the svn-buddy.phar release command
2. user is presented with interactive editor for entering the commit message (defaults to Releasing from {source path} to {target path})
3. user is presented with confirmation message like: Are you sure you want to release {source path} into {target path}
4. when user doesn't confirm an exception with User has aborted the workflow is thrown (see how it's done in commit command)
5. the {target path} folder is deleted in the repository via svn rm command (use above entered commit message)
6. the {source path} in repository is copied into {target path} path via svn cp command (use above entered commit message)

When optional --backup option is specified, then:

• when {target path} doesn't exist in repository, then throw an exception
• instead of svn rm command use svn mv command to rename {target path} into {target path}_YYYY-MM-DD (YYYY-MM-DD is date of last commit to {target path})
• the confirmation message and default commit message will have (backup: {target path}_YYYY-MM-DD) added to the end

When all revisions are merged (even if merge happened in several attempts and one commit made afterwards) and make that fact known to commit message generator.

Related to #9.

Usually output of svn-buddy.phar merge command looks like this:

 * Working Copy Status ... Up to date
 * Merge Source ... /projects/project_name/trunk
 * Merge Target ... /projects/project_name/tags/stable
 * Upcoming Merge Status ... 1 revision(-s) or 1 bug(-s) not merged
 * Previous Merge Status ... Successful

However in case if before detecting upcoming merge status the repository is queried for info about new revisions the output looks like this:

 * Merge Source ... /projects/project_name/trunk
 * Merge Target ... /projects/project_name/tags/stable
 * Reading missing revisions: 1/1 [============================] 100%
12 revision(-s) or 4 bug(-s) not merged
 * Previous Merge Status ... Successful

It seems, that when progress bar is done drawing it clears line after it and therefore * Upcoming Merge Status ... text is erased.

Maybe the bugs option needs to be renamed into tasks option. I prefer not to rename because people say Bug Tracker rather than Task Tracker.

There are several tasks about filtering enhancements:

• #18
• #17
• #15

plus there is already some filtering options available (e.g. by bugs or by path).

Need to create functionality, that will allow:

• defining new filters classes (each with own logic)
• automatically change cache version of RevisionLog upon filter added or it's logic changed
• adding of filters to RevisionLog in any order
• ask each added filter to process log record read from repository to collect needed sub-set of data to be filtered upon
• have access to revision log for basic data (e.g. paths changed in each revision)

Then it can work like this:

$filter = $revision_log->createFilter(array(
    array('path' => ...),
    array('bugs' => array(...)),
    array('revisions' => array(...)),
));

foreach ( $filter => $revision_id => $revision_data ) {
    ...
}

or similar.

Remove interactive part of "Repository\Command" class, because it isn't tested and is never used anywhere = dead code.

Currently merge commit message is revision oriented - prints revisions one by one even if they relate to same task:

Merging from Trunk to Stable
* r1111: PRJ-1234 - Task Description
1. change1 made in this task
2. change1 made in this task
* r2222: PRJ-5555 - Task Description
1. change1 made in this task
2. change1 made in this task
* r3333: PRJ-1234 - Task Description
1. change1 made in this task
2. change1 made in this task

Maybe the message format needs to be revised to list tasks and then revisions within them. That might look like this:

Merging from Trunk to Stable
* PRJ-1234 - Task Description
r1111:
1. change1 made in this task
2. change1 made in this task
r3333:
1. change1 made in this task
2. change1 made in this task
* PRJ-5555 - Task Description
r2222:
1. change1 made in this task
2. change1 made in this task

Create "aggregate.ignore" config setting that would define paths (one path per line) that should not be looked at during mass working copy detection.

I've moved repo from https://github.com/aik099/svn-buddy into https://github.com/console-helpers/svn-buddy. Need to update following:

• change package name in composer.json
• change package mentions within README.md and other files
• change links to repository in license blocks
• change repository mentions within README.md and other files
• confirm repo rename on Scrutinizer CI side and then:
  • change url of Scrutinizer CI badge
  • enable Scrutinizer CI Web Hook
• change namespace from aik099\ into ConsoleHelpers\

Don't push any commits until Scrutinizer CI will make changes.

Create the "after-update-cmd" config setting of array type.

1. each line in there is considered as Bash command and will be executed
2. the {wc_path} will be replaced with corresponding working copy path

Maybe the composer.json in the project can be adapted to executed post update stuff and SVN-Buddy will just call it.

When merging 70 revisions, then it's hard to see how much revisions are left. Showing progress info at the end if --- Merging r20146 into '.': line could be useful.

For example: --- Merging r20146 into '.' (5 of 70):.

Right the merge command shows number of unmerged revisions. Since each revision most likely have bug association then also showing bug count could be beneficial.

Plan:

1. add --auto-commit option to merge command, that when used would allow to automatically invoke svn-buddy.phar commit command if merge was successful (no merge conflicts)
2. add new merge.auto-commit setting of boolean type (false by default)
3. if user haven't provided --auto-commit option, then enable it based on setting value

Blocked by #26

When several bugs specified via --bugs option (e.g. --bugs 1111,222,333) and each of them have several associated revisions, then during merging revisions are not sorted from smallest to largest across all bugs, but only with each bug itself.

Need to replace occurrences of bug numbers (parsed from log message) with some short placeholder to save space.

In other tasks more possible columns would be added to output of log command. This would surely result in word wrapping on small Terminal windows. To avoid that a setting needs to be created, which:

• list visible columns
• controls order of the columns

In the Symfony Process 2.8 the call to the getWorkingDirectory was added in the ProcessFailedException class constructor. Since it's mocked the Prophecy is throwing exception because no matching mock method is defined.

1) Tests\ConsoleHelpers\SVNBuddy\Repository\Connector\CommandTest::testRunError
Exception of correct class was thrown
Failed asserting that Prophecy\Exception\Call\UnexpectedCallException Object (...) is an instance of class "ConsoleHelpers\SVNBuddy\Exception\RepositoryCommandException".
/home/travis/build/console-helpers/svn-buddy/tests/SVNBuddy/Repository/Connector/CommandTest.php:383

Add --merged-by option (accepts revision list), that would:

• confirm, that each of given revision represents merge commit (see #15)
• display revisions, that were merged by given commits

Currently the log command only prints first line of log message even if --details option is used.

I think that in details view full message needs to be printed.

Right now --revisions option can have all value, that mean merge all non-merged revisions. To be more human friendly the --bugs option must also accept all value, that would mean merge all bugs.

Currently the absolute merge source url only is supported, e.g. svn://[email protected]/in-portal/branches/5.2.x. Since the merge is happening inside a working copy the svn://[email protected]/ part is already known.

Proposing to replace the ^ in the front of the given merge source url with the corresponding part from working copy checkout url.

When --glob option is specified, then from revisions at given path scan changed paths and match them to glob expression given in --glob, e.g. */**/some_file.php.

Plan:

• lift restriction, that prevents reading/writing config settings from other commands
• add merge.recent-conflicts array-type config setting (empty by default)
• when merge command is used and it ends up in merge conflict, then add all conflicted paths to the merge.recent-conflicts working copy setting
• when revert command is used, then clear the merge.recent-conflicts working copy setting
• when commit command is used AND merge.recent-conflicts config setting isn't empty, then add following text after regular commit message:

Conflicts:
 * /conflicted/path/one
 * /conflicted/path/two

• when commit command is used and user agrees to make commit, then:
  • make commit
  • clear the merge.recent-conflicts working copy setting

The Phabricator tool, that shows commits is parsing commit messages using it's own Markdown-alike parser. The currently generated merge commit message looks very bad, when rendered:

The following must be attempted (only for commit with 2+ lines):

• if 2nd line of message present and doesn't look like list (1. or - or *), then wrap 2nd+ till commit message end line using Fenced Code Block
• otherwise ident using each line after 1st one using 1 space

Right now if svn-buddy is used on several projects and each of them have created 4 cache files each, then the cache folder would contain 9 files (8 cache files + 1 config file). The more projects/cache files there are the harder is their management (if human ever decides to do something with them).

When cache is about to be used create a sub-folder per working copy (or repo path) and place related cache files in there.

No existing cache file migration is needed, because as any cache it will be recreated once missing.

Maybe will become obsolete when #55 is implemented.

The diff command would initially offer any several options:

• have --revisions (-r) option for specifying revision or their range
• have --stat option, that would pass through result of diff to the diffstat app and colorize the output to have green + and red - as during git pull command

When --stat option is used check that diffstat app is installed and if it's not throw an exception.

https://travis-ci.org/console-helpers/svn-buddy/jobs/94038162

In other tasks more possible columns would be added to output of log command. This would surely result in word wrapping on small Terminal windows. To avoid that a setting needs to be created, which:

• list visible columns
• controls order of the columns

When outdated command will be executed on a working copy, then it would:

• show green Working copy is up to date. message, when no update is necessary
• show list of missing revisions (ones present in repository, but not in working copy), when working copy is outdated

To determine outdated working copy we need to:

• get last changed revision of working copy root from repository (e.g. /trunk or /tags/stable)
• get current working copy revision
• if repository revision is greater than working copy ones, then working copy is outdated
• --revisions=X-Y argument can be supplied to log command call to show only missing revisions, where X is working copy revision and Y is repository revision

Mixed-revision working isn't considered as an outdated.

When merge source url can't be detected, but project url can be detected, then allow user to select from existing tags/branches on a project except current one.

When new config setting value matches following criteria it should not be stored and setting itself should be deleted:

• when I'm editing global value AND it matches default value
• when editing working copy value AND it matches global value (only when global value is set)
• when editing working copy value AND it matches default value (only when global value is not set)

Otherwise attempt to change config setting value would break the inheritance immediately.

The results of commonly used SVN commands are cached. Some caches are time-based and some are criteria based.

• The criteria-based caches are reset automatically when criteria is changed and are not time-based.
• Time-based caches however are more tricky, because they are not reset until certain time passes.

For example last commit detection in repository only is refreshed once per 25 minutes.

The svn-buddy.phar touch command would need to:

• locate all time-based caches associated with current working copy
• reset them

From list of revisions specified by --revisions (or --bugs) option we need to exclude revisions specified by --except-revisions (or --except-bugs) option.

That would be a help during huge merges when large set of revisions/bugs needs to be merged but still some of matched above should be excluded from merge.

Currently the log message format for merge commits is hardcoded and looks like this:

Merging from Trunk to Stable
* r1111: PRJ-1234 - Task Description
1. change1 made in this task
2. change1 made in this task
* r2222: PRJ-5555 - Task Description
1. change1 made in this task
2. change1 made in this task
* r3333: PRJ-1234 - Task Description
1. change1 made in this task
2. change1 made in this task

This is by revision printing. In #7 a suggestion is made to change that format to another one, which by bug printing.

Instead I propose to add commit.merge-message-format setting, that would allow to select from list of supported formats. To make this happen the config command needs to be changed to allow selection from fixed list of options instead of opening interactive editor for this new setting.

Possible formats:

• auto
• by revision
• by task
• summary only

By default auto format would be selected, that will split merged revisions list into 2 groups:

• ones that have task
• ones that don't have task

Then corresponding commit message would be generated for each group and combined into final message.

Keep list of revisions by author in the RevisionLog class. When --author is specified then filter revisions by path also by their author.

Do auto-complete author names from known ones to RevisionLog.

Blocked by #19 , because will increment cache version.

1. in the RevisionLog class add constant to indicate current log cache format version
2. if after reading revision log cache the cache version is missing or is smaller then needed (there can be log caches in different versions for different repos), then consider this as missing log cache and rebuild it from scratch