Revision number should be stored in review issue in case project from repository is reviewed

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Make a CVS/SVN project
2. Add some review issues to a file
3. Modify the file later (e.g. by adding some lines/methods etc.)
4. Open review again

What is the expected output? What do you see instead?

The issues are totally in wrong places since they probably store only line
number. There should be a possibility to automatically store number of
revision from repository to which a review issue was created. That
information could be then used to either get manually/automatically this
revision from repository and see where actually the issue was placed OR try
to automatically find a correct line in current revision.

What version of the product are you using? On what operating system?

Jupiter 3.4.1.1 with Eclipse 3.3.1.1 on Windows XP

Original issue reported on code.google.com by dstank...@gmail.com on 3 Dec 2008 at 10:25

[GoogleCodeExporter]

This is difficult.  This forces Jupiter to have to know about all version 
control
systems.  There is a CVS plugin that comes bundled with Eclipse but there isn't 
any
SVN one.  So I don't know how Jupiter would access it.  I'm assuming the vast
majority of SVN users in Eclipse use Subclipse or Subversive but there are 
probably
others.  I'm not even sure if the CVS code is accessible.  From what I've seen 
it is
all marked as discouraged access.

Original comment by jsakuda on 3 Dec 2008 at 7:38

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Another option is that when creating review id, there's field to fill in 
manually
revision number which is reviewed. And adding an issue could automatically add 
to xml
content of the line it is assigned to possibly together with some context, e.g.
content of 3 lines back and forward. That would make it possible to find such a 
line
later, even manually, if file is changed. Otherwise, if the author of an issue
doesn't write good description, it may be unfindable...

Original comment by dstank...@gmail.com on 5 Dec 2008 at 8:49

[GoogleCodeExporter]

You may create a branch for code review -- this way the code will not be 
changed by
external development.

While editing the code with proper review loaded, the tags are moved properly 
(even
with other perspective than Jupter). 

And then, if there were many reviewers, create additional branch for each 
developer
for the rework phase (so they won't mix up their issues).

It is some additional work, but might help.

Original comment by aleksand...@poczta.onet.pl on 31 Aug 2009 at 3:25

[GoogleCodeExporter]

Sorry, this is more of a note to myself but it is related to this issue.

The following code I think may help accomplish the saving of the revisions and 
such.  However, I think this will only work in Eclipse if the project has been 
imported and correctly recognized by one of the SCM plugins (i.e. CVS, 
Subversive, Subclipse, EGit).

RepositoryProvider provider = RepositoryProvider.getProvider(project);
SyncInfo syncInfo = provider.getSubscriber().getSyncInfo(resource);

SyncInfo has getLocalContentIdentifier() which is some kind of revision 
identifier (this would vary depending on what VCS is backing the project).  It 
also allows access to the Remove and Base revisions of the resource being used 
I believe.

Original comment by jsakuda on 25 Jun 2010 at 8:59

[GoogleCodeExporter]

This is a major issue for jupiter. VCS is even more essential to 
software-development than doing reviews. IMHO without any support in this area 
jupiter is not usable for real-life projects.
Maybe as a very first step you can calculate the hash (md5) of the source and 
store it with the review when it is saved. This will at least allow to detect 
that the file has been modified outside (even without relation to VCS) since it 
was reviewed last time. Then a warning popup could show up.
For the long run there should be some thought how to integrate with VCS. 
Eclipse seems to have a general concept for VCS integration. Doesn't if offer 
some abstraction to get a revision number, etc.? Otherwise you could also have 
a look at maven-scm that offeres a generic API to various VCS.

Original comment by joerg.ho...@googlemail.com on 19 Jan 2011 at 11:58