Revisions of externals in Powerbuilder

( SVNSCC , PowerBuilder, 1.5.1.2, WIN 2000/XP )

Type: Public Status:Closed Created: 16 Mar 09 03:00 Updated: 30 Apr 09 04:00

--> Oleg Akolupin (admin) at 30 Apr 09 04:00 writes

It was released SVNSCC 1.6.0.RC0.
You can download it here :
http://www.pushok.com/soft_download.php?idprogram=3

--> Oleg Akolupin (admin) at 29 Apr 09 04:00 writes

It was released 1.5.1.3 version of SVNSCC.
You can download it here :
http://www.pushok.com/soft_download.php?idprogram=3

--> Peter Pöltl (user) at 06 Apr 09 04:00 writes

If those externals with explicitly specified revisions are readonly then of
course we got another situation... Have to say, I did not find this
documented so far!?

Thanks,
Herbert

--> Alexander Somov (admin) at 06 Apr 09 04:00 writes

It would be better to consider that external repositories are read-only
when you explicitly specify revision numbers in your externals definitions.
It was assumed that this is the way it should work: you get a snapshot of
an external project, and it will stay immutable until you change
svn:externals in order to get another snapshot. If you want to participate
in the development of the project, you should not specify a revision number
in the external link. You will work with the HEAD revision in this case.

The situation you have described is possible only when the class is not
changed since rev. 20. Otherwise, if somebody else have changed this class
and already committed rev. 21, check-in will fail and SVN will complain
that the file is out of date. In this case you should update the file
before checking in, but you can't do it using GLV, because you have limited
revision of this external link to 20. There are several ways to get out of
this situation, but the main thing is clear: normal operation is impossible
in this configuration.

Maybe it would be better to show warning or even forbid checkout in such
cases.

--> Peter Pöltl (user) at 03 Apr 09 04:00 writes

Thank you for this info, Alexander, and for scheduling another 1.5
release.

In concern to the svn update topic: At any time I'll have to commit the
external property of course, and as far as I remember that is the moment
when SVN requires having done an update before. So I think the best way is
to always update immediately after having changed an externals property.

But I have to say I still don't know if I'm completely happy with the
SVNSCC release you provided. Let's assume I got an external folder in my WC
and the external property points to the head revision of the external
folder, say 20. Now I make changes to a class in this external folder and
would like to commit them. So I run a PB "check in".

Now SVNSCC via PB tells me it had committed revision 20 - which is wrong
cause it actually committed release 21. Afterwards the class is signalled
as out of sync, which might also be wrong because the external property
still points to revision 20.
Then I leave PB and change the external property to 21. Now after a restart
PB still signals "out of sync" for this class (only for this class). A
refresh does not change that status. Then I do a GLV on this class - and
gee, this brings up the "in sync" icon again.

Maybe you could be so kind and give some kind of best practice advice for
this situation.

Kind regards,
Herbert

--> Alexander Somov (admin) at 30 Mar 09 03:00 writes

I think, "svn update" before GLV is not required, unless you have
incremented the revision of an external property not in your working copy
but in the repository, and you want to synchronize them.

All SCC functions (such as SccGet, SccQueryInfoEx etc.) use the value of
the svn:externals property that is present in your wokring copy.

MSSCCI is a file-oriented API (in particular, PowerBuilder uses it that
way), so the plug-in will update only files, not directories. As a result,
after GLV you will get a working copy in which the files have newer
revisions than the directories. Since the svn:externals property is set on
a directory, it will never be updated with GLV, and you have to use an
external tool to update it.

About the 1.5.* line. OK, there will be at least one more release, based on
SVN 1.5. I think it's reasonable.

--> Peter Pöltl (user) at 27 Mar 09 03:00 writes

Thanks for this explanations, Alexander. I can confirm that after doing a
complete GLV PB now calls all objects "in sync" - and they remain "in sync"
on a status refresh. When I increment the revision of the external property
for some folder PB recognizes the repository revisions more recent and
signals "out of sync". So everything looks good to me.

If you allow one more question on this: When I increment the revision of an
external property on a folder as mentioned above, I would say I have to do
a "svn update" before I do a PB GLV. Would you agree on that?

But for sure we appreciate the fix you provide. We would prefer a minor
update of the 1.5.* line because we don't like to migrate to 1.6 already.
If you might consider this!?

Kind regards,
Herbert

--> Alexander Somov (admin) at 27 Mar 09 03:00 writes

The fix is that SccQueryInfoEx now reports not the latest revision in the
repository but the latest revision that was actual on the moment specified
in the external link.

SccQueryInfoEx is a non-standard, PowerBuilder-specific extension to MSSCCI
API that is used to determine which files have changed in the repository
and require updating. When you run "Get Latest Version", PowerBuilder calls
SccQueryInfoEx and stores the reported revisions. When PB performs the
status update, it calls this function again, and if the revisions differ
from those reported during GLV, it considers that the files are out of
sync.

So, to see that the fix is working, you need to execute "Get Latest
Version". It doesn't actually update the files, but it updates the
information about the latest revisions.

This fix will be included in the next version of the plug-in. I think it
will be already based on SVN 1.6.0 and should be released within one or two
weeks.

--> Peter Pöltl (user) at 26 Mar 09 03:00 writes

Thank you! Half the way I would say.

I opened the same workspace using the new DLLs you provide.

The same external classes as before - for which higher revisions exist -
are still signalled "out of sync" despite the limiting externals setting. A
"refresh status" does not change that. All those classes are still proposed
for GLV. If GLV is executed, the correct version - according to the
externals setting - is fetched and signalled AFAICS. Afterwards PB shows
this class as "in sync"!

The "SCC properties" dialog now shows the correct versions of the classes
in the working copy (= workspace).

So the signalled revisions seem ok to me now. I still wonder why those
classes are "out of sync" - and why they are in sync after the same
revision as before has been fetched.

Maybe you could provide a new release soon?

Kind regards,
Herbert

--> Alexander Somov (admin) at 25 Mar 09 03:00 writes

Try the updated DLLs:

http://www.pushok.com/files/temp/svncom_1512r.zip
http://www.pushok.com/files/temp/PushokSVNSCC_1512r.zip

Unzip and overwrite existing. Then execute "Get Latest Version". Does it
work as expected now?

--> Peter Pöltl (user) at 16 Mar 09 03:00 writes

For a certain project we work with SVN 1.5.6 and Powerbuilder
9.0.3. The SVNSCC setting "check revs for svn:externals" is active -
besides, I still cannot find any documentation on it.

I got a working copy in a folder say PRJ. On this folder the external
property is set to import some revision - say rev 10 - of another
repository to some subfolder, say PRJ\EXT. Let the head revision of the EXT
repository be 20.

In this situation PB signals those classes as "out of sync", for which
higher revisions exist in the repository - despite the "externals" setting
telling him that no higher revision is wanted. PB's system tree class
property sheet shows up the repository's head revision for those classes
despite revision 10 is present in the working copy.

Also, all classes in the externals folder with higher revisions than 10 are
proposed for a "get latest version" PB operation. But if you let PB execute
this GLVs, it retrieves revision 10 again, despite the SVNSCC update
message tells it would fetch the head revision...!

Is all that expected behaviour? To me this seems confusing! At least the
info on the current and the retrieved revisions should be correct,
shouldn't it?

Kind regards,
Herbert

Rate this ticket:

Not useful at all

Partially useful

Useful

Very useful

Ticket

Revisions of externals in Powerbuilder