ivantage / grunt-ivantage-svn-changelog Goto Github PK

Really the exact same issue as jtrussell/semver-tags#4, so perhaps it would do well to have the same solution. svn info "^/tags/" + tag, on line 215 chokes when dealing with nested repositories (“svn: E200009: Could not display info for all targets because some targets don't exist.”)

I manually updated to v0.4.0 when I saw that you had implemented the svn-project-root module and was happy to find that it works! However, though it generated the changelog contents and successfully committed it to SVN, it also generated a warning and aborted the grunt task with this text:

Warning: Could not check CHANGELOG into version control Use --force to continue.

I checked the tasks/ivantage_svn_changelog.js and am fairly confident I see the problem, though it makes me confused about how the task is supposed to work. At :149, the task runs svn add CHANGELOG.md, then follows it up with the svn commit, then checks the sum of the result codes from both commands to determine if it worked. Because I already have CHANGELOG.md in my repo, the svn add command returns:

svn: warning: W150002: '/Users/path/to/CHANGELOG.md' is already under version control
svn: E200009: Could not add all targets because some targets are already versioned
svn: E200009: Illegal target for the requested operation

and so the task generates a warning.

My confusion/question: is this task designed to preserve previously generated changelog content? If so, I imagine :144 should be something like (naïve version):

grunt.file.write(opts.outFile, changelogMd + grunt.file.read(opts.outFile));

Use blargus for a small dummy svn repo.

Hi,
When options revFrom or revTo is set with NaN value 'HEAD' or 'LAST_SEMVER_TAG' it seems that the command svn log -r revFrom: revTo is never called .

The changelog file contains only the two revision numbers return by the command svn info.

It would be a great tool if the svn log command was called after the recovery of the revision numbers to generate the changelog accordingly to the history referenced by the revision numbers.

Best regards.

See #5 (comment)

The task is assuming it should create a fresh changelog every time it's run(i.e. every release). It should use a default name that's consistent with that assumption.