Stefan.Fuhrmann_at_etas.com wrote:
> Hm. It depends on what we want to show. In my opinion,
> the user wants to know what his "current position" is
> within the revision graph.
>
> Using GetFirstFileInfo, I mark the last changed revision
> for single files and folders alike. Usually there is a
> already a corresponding node in the graph (for obvious
> reasons). To me, this is an exact description of what
> "my current position" within the changes graph is.
The problem is for folders. The last-changed-revisions for folders is
usually the one where you last changed a property: how often does that
happen?
Also, for single-developer projects, you don't run 'update' very often.
Usually only if you get an out-of-date error on commit due to some
folder properties changed. In that case, the revision you get for e.g.
the working copy root folder could be hundreds below the actual revision
of the working copy.
> I tried a number of paths in the TSVN /trunk tree and
> for all of them, GetFirstFileInfo()->lastchangedrev
> gives the same value as the maxrev out-parameter of
> GetWCRevisionStatus(). As this lastchangedrev info should
> be present in any working copy ever since SVN 1.0,
> we can rely on both calls yielding the same results
> at least for 1.5.x.
Because: when you run update, the revision of the folder changes to the
revision of the update (in case some file inside that folder also got
updated).
> Things become complicated with mixed revision WCs.
> This can only be an issue with folders. GetWCRevisionStatus
> might return a higher number here, if only some deeply
> nested sub-folder got updated.
Can't check right now (no access to tsvn code here), but isn't there a
param to exclude externals in that method?
> But as long as we don't want to say "mixed revision"
> in the graph while not marking any revision, I think
> marking the revision of the selected path is The Right Thing.
>
> If you should disagree here, I would rather make it an
> option to mark the current revision. Some working copies
> here at the office are more than 10 time as big as TSVN
> (excluding externals in both cases). Crawling them is
> a big issue while it isn't for TSVN-sized projects.
In that case, I'd say we have to go for making this optional. Because
the folder revision really *is not* the revision the working copy is on
(otherwise: what's the point of SubWCRev??).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-03-04 13:47:47 CET