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
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
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
--
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.