#3499: Latest revision number not written correctly to hdf
---------------------------------+------------------------------------------
 Reporter:  [EMAIL PROTECTED]  |        Owner:  cboos
     Type:  defect               |       Status:  new  
 Priority:  normal               |    Milestone:       
Component:  version control      |      Version:  devel
 Severity:  normal               |   Resolution:       
 Keywords:  needinfo             |  
---------------------------------+------------------------------------------
Changes (by anonymous):

 * cc: [EMAIL PROTECTED] (added)

Comment:

 I apologize, you are right. I assumed that the revision number should be
 shown in the "view revision" field since this is the behavior of Trac
 0.9.5. I now see this is not the case (i.e. on trac.edgewall.com) and I
 assume this has been changed ? (( I don't see why, though, I found it
 quite informative. Even though the number is shown in the "view revision"
 you still follow the youngest branch as the "rev" argument is not included
 in the HTTP request unless you specifically put in a number and press
 enter. ))

 I also found that the error wasn't tied to the revision number ''not being
 shown'' (although changing the HDF as shown in the Ticket description
 fixed the problem). The ''real'' problem is in `versioncontrol/api.py` -
 or `p4trac.py`, dependent on how you look at it.

 Problem:
   * Go to BROWSER
   * Browse to you favorite path
   * Click "View Changes"

 This submits you to
 /trac/anydiff?new_path=xxx&old_path=xxx&new_rev=&old_rev=. The problem is
 that "new_rev" and "old_rev" are defined as zero length strings of type
 Unicode, but not as type None. The error is triggered in p4trac.py's
 implementation of normalize_rev when rev is casted to an integer.

 I first though this was an error in p4trac.py but as it turns out,
 p4trac.py is according to [source:trunk/trac/versioncontrol/api.py
 Versioncontrol's API] (see line 197):

 {{{
 def normalize_rev(self, rev):
     """
     Return a canonical representation of a revision in the repos.
     'None' is a valid revision value and represents the youngest revision.
     """
 }}}

 According to this, `normalize_rev` should be called with either a number
 (in a Unicode String that can be casted with `int()`) or None. The reason
 why this works with SVN is that `versioncontrol/svn_fs.py` catches the
 exception and set's rev=None if the casting failed. That is, does more
 extra checks then the API states should be necessary.

 Not sure you agree, but I'd say that either `normalize_rev` shouldn't be
 called with u'' or that the API's documentation should be updated to state
 that both None and u'' are valid revision values.

-- 
Ticket URL: <http://trac.edgewall.org/ticket/3499#comment:4>
The Trac Project <http://trac.edgewall.com/>
_______________________________________________
Trac-Tickets mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-tickets

Reply via email to