Changes I would like to see in ZAKE

90 views
Skip to first unread message

evp

unread,
Apr 14, 2010, 11:21:32 AM4/14/10
to SAPlink
I realized I can't get ZAKE to work the way I would like it to work.
Or may be I misunderstood something.

Here is how I can see ZAKE helping me. Not sure if this is the vision
for ZAKE. Some of the steps I'm describing here are already
implemented in ZAKE

1) I am only interested in "pure" svn functionality. Tortoise is fine
but I don't really need it

2) Checkout
* 'svn checkout' command is called. The directories and files are
created in the local path
* ZAKE goes through all directories and finds *.SLNK files
* ZAKE loads (creates) all found *.SLNK objects into SAP.
* ZAKE has to remember (table or local file) the mapping between an
SAP object and its SLNK file
For example: ZSLQA_RUNNER (CLAS) is in F:\Projects\EVPnet\saplink-
unit-tests\slqa\CLAS_ZSLQA_RUNNER.slnk
* ZAKE has to calculate and remember (table or local file) MD5 hash
(function module MD5_CALCULATE_HASH_FOR_RAW) can be used for every
SLNK file that it loads into SAP
* ZAKE already does syntax check and activation
* ZAKE remembers the SAP package name and how it is mapped to the
local path
For example, package ZSLQA is in F:\Projects\EVPnet\saplink-unit-
tests

3) Checkin (commit in SVN terminology)
* ZAKE is given an SAP package name
* If ZAKE knows the mapping between the package and the local path the
processing starts.
If not, the user is asked to enter a local path. ZAKE remembers the
path and its mapping to the package
* ZAKE goes through every object in the package and creates a SLNK
file in the temp location. Or this can even be done in memory.
MD5 is calculated for the SLNK document
* If ZAKE knows the local SLNK path of the object then:
If current MD5 is not equal previous MD5 the SLNK file is created in
the local path
If current MD5 is equal previous MD5 nothing should be done
The current MD5 is calculated and remembered
* If ZAKE does not know the local SLNK path of the object then:
The user is asked to enter the local path
The MD5 is calculated and remembered
The SLNK file is created in the local path and 'svn add' is executed
* 'svn commit -m <comment>' command is called

4) There should be an option not to compare current MD5 with the
previous and simply create SLNK for every object in the package

5) There should be an easy access to the mapping of package objects to
SLNK files and MD5 hash in case a user wants to change something

Am I steering away from what ZAKE is intended to be?

If ZAKE works in the way I described it would really help because I
already had situations where my objects in SAP were out of sync with
the SVN repository.

Let me know what you think.

-Edward

Gregor Wolf

unread,
Apr 14, 2010, 6:04:24 PM4/14/10
to sap...@googlegroups.com
Hi Edward,

thank you for the extensive write up.

> 1) I am only interested in "pure" svn functionality. Tortoise is fine
> but I don't really need it

I've added support for TortoiseSVN because of it's possibility to handle
conflicts. As you've already found out, that you can't interact with the
command line svn client because I've forwarded the output to a file.
TortoiseSVN allows you to be interactive and display the conflicts when they
occur before you start importing in the ABAP system.

> 2) Checkout
> * 'svn checkout' command is called. The directories and files are
> created in the local path
> * ZAKE goes through all directories and finds *.SLNK files
> * ZAKE loads (creates) all found *.SLNK objects into SAP.

Up to this point it's exactly as ZAKE_SVN works.

> * ZAKE has to remember (table or local file) the mapping between an
> SAP object and its SLNK file
> For example: ZSLQA_RUNNER (CLAS) is in F:\Projects\EVPnet\saplink-
> unit-tests\slqa\CLAS_ZSLQA_RUNNER.slnk

I don't use a table or local file to have a mapping between the SAP object
and the file system. When I do the first export using ZAKE_SVN all the
exported files from the ABAP system are created in this Structure:

<Package Name>
<Object Type>
<Object Name>.slnk

By sticking to this convention I've avoided to maintain such a file or
table.

> * ZAKE has to calculate and remember (table or local file) MD5 hash
> (function module MD5_CALCULATE_HASH_FOR_RAW) can be used for every
> SLNK file that it loads into SAP

I don't take MD5 hashes. When I do the Checkin/commit I export all the files
of a package or a user defined object table. If an Object was not changed in
the ABAP system, SVN will not recognize any change in file. The file has
just a new timestamp. But there is a problem with the current behavior of
SAPlink when it creates Slinkees:

1. As you already pointed out the encoding of the Slinkee depends on the
system codepage. In my case iso-8859-1. When I do changes on a Unicode
system, then the file is encoded in UTF-8 or 16.
2. In the main tag of every object SAPlink exports attributes like:

VERSION="1"
AUTHOR="BCUSER"
CREATEDON="20100112"
CHANGEDBY="BCUSER"
CHANGEDON="20100307"
R3RELEASE="701"

When changes are done on another release or with another user that results
in a change of the file and needs to be checked back into the repository.

> * ZAKE already does syntax check and activation

It currently does only activation. Is there a way to do just a syntax check
first? Function Module/Class?

> 3) Checkin (commit in SVN terminology)
> * ZAKE is given an SAP package name

When you provide a package name then all objects of this package are
exported. The alternative is to build up a table as in the demo program
Z_ZAKE_SVN_TEST or also the Z_ZAKE_SVN program that I use to commit to the
SAPlink Google Code subversion repository.

> * If ZAKE knows the mapping between the package and the local path the
> processing starts.
> If not, the user is asked to enter a local path. ZAKE remembers the
> path and its mapping to the package

As you can see in the demo programs I use ABAP to define the path. I don't
think that more is needed because it is a developer tool. Perhaps I should
also here support relative path names based on the now supported ZAKE_HOME
environment variable.

> * ZAKE goes through every object in the package and creates a SLNK
> file in the temp location. Or this can even be done in memory.
> MD5 is calculated for the SLNK document

As mentioned before I don't take a MD5 hash. I just export all the Slinkees
to the location specified in the program.

> The SLNK file is created in the local path and 'svn add' is executed
> * 'svn commit -m <comment>' command is called

This steps are done as you think.

> 4) There should be an option not to compare current MD5 with the
> previous and simply create SLNK for every object in the package
>
> 5) There should be an easy access to the mapping of package objects to
> SLNK files and MD5 hash in case a user wants to change something

Let's see if MD5 is needed anyway.



> Am I steering away from what ZAKE is intended to be?

No, you've got the point.

> If ZAKE works in the way I described it would really help because I
> already had situations where my objects in SAP were out of sync with
> the SVN repository.

This is my work flow do to avoid such situations with my 3 projects I'm
currently working on:

1. Do a SVN update at the beginning
2. Do the changes in the ABAP system
3. Test the changes
4. Run Checkin/Commit in test mode to see what files where affected
(TortoiseSVN is helpful here again because of it's Windows Explorer
integration)
5. Do the final Checkin/Commit

Best regards
Gregor

evp

unread,
Apr 15, 2010, 11:38:16 AM4/15/10
to SAPlink
> > 1) I am only interested in "pure" svn functionality. Tortoise is fine
> > but I don't really need it
>
> I've added support for TortoiseSVN because of it's possibility to handle
> conflicts. As you've already found out, that you can't interact with the
> command line svn client because I've forwarded the output to a file.
> TortoiseSVN allows you to be interactive and display the conflicts when they
> occur before you start importing in the ABAP system.

I came across the problem with the svn cmd window waiting for input
after I posted this discussion.
I will check how TortoiseSVN works in this situation.

> I don't use a table or local file to have a mapping between the SAP object
> and the file system. When I do the first export using ZAKE_SVN all the
> exported files from the ABAP system are created in this Structure:
>
> <Package Name>
>   <Object Type>
>     <Object Name>.slnk
>
> By sticking to this convention I've avoided to maintain such a file or
> table.

Let me disagree on this one.
I think ZAKE should offer an alternative (custom) mapping for the
projects where grouping of SLNK files is dictated by the project
logic.

You can offer a default (<Package Name>/<Object Type>/<Object
Name>.slnk) or custom mapping.

> I don't take MD5 hashes. When I do the Checkin/commit I export all the files
> of a package or a user defined object table. If an Object was not changed in
> the ABAP system, SVN will not recognize any change in file. The file has
> just a new timestamp. But there is a problem with the current behavior of
> SAPlink when it creates Slinkees:
>
> 1. As you already pointed out the encoding of the Slinkee depends on the
> system codepage. In my case iso-8859-1. When I do changes on a Unicode
> system, then the file is encoded in UTF-8 or 16.

Yes, I will be working on adding explicit codepage (encoding) support
to my copy of SAPlink
Once that is fixed ZAKE can have a selection of encoding in which the
project is stored (default is probably UTF-8).

> 2. In the main tag of every object SAPlink exports attributes like:
>
> VERSION="1"
> AUTHOR="BCUSER"

> ...


> When changes are done on another release or with another user that results
> in a change of the file and needs to be checked back into the repository.
>

I will take another look at this. If the attributes change the MD5
hash will be changed and that defeats the purpose...

>
> It currently does only activation. Is there a way to do just a syntax check
> first? Function Module/Class?
>

Let me check this one. I thought I saw in one of ZAKE related
documents a reference to CL_SLIN=>RUN( )

Regards,
Edward

Dan McWeeney

unread,
Apr 15, 2010, 12:04:14 PM4/15/10
to sap...@googlegroups.com
Sorry still working on my response, it might be turning into a blog on what ZAKE was/is supposed to be and what it means for ABAP developers.  Most of Gregor's comments are inline with my thinking but, there are some divergent ideas I really want to share.

I am in the middle of a Quality Sprint at work so, the post likely won't see the light of day till the end of this weekend but, fear not I am thinking about all this.

-d


--
You received this message because you are subscribed to the Google Groups "SAPlink" group.
To post to this group, send email to sap...@googlegroups.com.
To unsubscribe from this group, send email to saplink+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/saplink?hl=en.


Taryck BENSIALI

unread,
Apr 15, 2010, 1:28:11 PM4/15/10
to sap...@googlegroups.com
Hi,

About mapping file to object, I had the same questionning between using :

> <Package Name>
>   <Object Type>
>     <Object Name>.slnk
or something else.
The danger of using Package in the file location is that if you have to change you package you'l lost the "link" in google code for the file changes. That why I use :
>   <Object Type>
>     <Object Type>.<Object Name>.slnk

The unique ID of an object is :
  • type
  • name
So it seems that nothing else should be used in the file location, I think. But allowing customization event with inheritence might be possible to prevent have your own version of ZAKE.

FYI this point is a problem on Mercurial (vs SVN) :

> I don't take MD5 hashes. When I do the Checkin/commit I export all the files
> of a package or a user defined object table. If an Object was not changed in
> the ABAP system, SVN will not recognize any change in file. The file has
> just a new timestamp. But there is a problem with the current behavior of
> SAPlink when it creates Slinkees:
If file time stamp change, file is send again as new version.

For fixing this point :

> 2. In the main tag of every object SAPlink exports attributes like:
>
> VERSION="1"
> AUTHOR="BCUSER"
> ...
> When changes are done on another release or with another user that results
> in a change of the file and needs to be checked back into the repository.
>

I've added a "cleanning" method that remove SAP system specific informations such as :
  • date
  • time
  • user
  • SYSID
  • ...
It has to be implemented for each component kind. When using this cleanning method and MD5 checksum you'll be able to detect changes, but not synchronisation conflicts, which is the main problem.

Last point : Exceptions class
When changing the exception text or just importing an exception class, exception text GUID is changed.
After a fresh install or update ZCX_SAPLINK will be exported and push to repository just because text GUID has change.
See this issue.

Taryck.

evp

unread,
Apr 15, 2010, 9:56:42 PM4/15/10
to SAPlink
Just to confirm that SVN does not think the file is modified if only
the time stamp on the file changed.

I tested this:

* with the svn command line and the 'touch' command
* with Z_ZAKE_SVN_TEST program. If you run Checkin two times in a row
the first time it does modify all SLNK files due to changes in
attributes. The second time only the time stamp changes on the SLN
files and therefore no new revision is created
Reply all
Reply to author
Forward
0 new messages