lcVCS problem

A place to discuss Version Control in LiveCode

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller

lcVCS problem

Postby seyabrill » Fri Apr 29, 2016 5:37 am

Hi,

I have a Project composes of Master stack and 73 substacks. I used lcVCS plugin to convert the Master stack to .vcs and created a repository so that my team can collaborate the changes in the project. It took some time to finish the whole process. Can anyone give advice to make this easy and not time consuming? Any advice that I can use the lcVCS effectively?

I made small changes like a comment on the card script of one of my substack. Saved the Master stack then use lcVCS to convert it back .vcs. Before committing it to my repo, I check the differences. It seems to me that there are lot of changes going on aside from the comment I created. Is there a way to locate the change that I made so that I can only commit that part?

One of my team convert back the .vcs folder to .livecode. He found out that some of the Data inside the stack was not complete. Some were gone, like data inside an array. Anyone have any idea why this happened? How can we avoid this to happen again?

By the way we are using lcVCS-1.0.0rc1, mergJSON-GPL-1.0.23. We also use tortoiseSVN.


Hoping for your positive replies. :)
seyabrill
 
Posts: 5
Joined: Mon Apr 11, 2016 8:47 am

Re: lcVCS problem

Postby Martin Koob » Fri Apr 29, 2016 6:50 pm

Hi

There are ways to get a handle on false diffs. One of the reason these are created is if the properties of objects change whether intentionally or unintentionally. This could be as simple changing as height or width or location. You can eliminate these by putting an lcVCSExport handler in each of the controls where you notice false diffs and in that handler you set a default value for each property that can change during the operation of your stack.

As you said one of the challenges is knowing which object the false diff is from. I use SourceTree to work with my repository. It has a feature to add custom actions. I have added a custom action that will show me the name of a selected object. That custom action is set in SourceTree preferences>Custom Actions. See the attached screenshot for the values to enter to create the custom action.

When you use the 'object name' custom action you get something like this:

lcvcs name -file components/LogIn.livecode.vcs/0c/d8c119-69d7-49a1-bef9-ab2ec0a549c3/properties.json -repo /Users/martin/Documents/Developer/myapp_repo/my-app
button "Back" of card "myLogin" of stack "UserLogIn"
Completed successfully

So on one line you can see the name of the object. In SourceTree you can see the parameters that changed to cause the diff then you can add an lcVCSExport handler to that object to set a default value when lcVCS exports it so there is no false diff generated.

Recently I have made a lot of changes to my app and I have not kept up with using the lcVCSExport handler. I have used few different approaches to deal with the false diffs. If I know I am only changing scripts I sort the objects by file name only select the scripts.utf8 files before committing. This way the false diffs are not committed to the repository.

If I know I have made changes to and object like location, size or other properties I can use the object name custom action to search through and find the object I modified and only select that object for commit. Same thing If I know I have created new objects.

Figuring out which diffs are valid or not can get time consuming so often I just select all of them and commit all changes whether or not they are false or actully intended changes. Probably not the best approach but I have not have had any problems doing that. However I am working on this with only one other developer at the moment and I don't have more than two branches at a time.

I really find lcVCS invaluable and even with the small inconvenience of the false diffs that can be generated I think it is a productivity enhancer.

For more info on using lcVCS Heather wrote an article here.
https://livecode.com/version-control-for-livecode/

Martin Koob
Attachments
Screen Shot 2016-04-29 at 1.32.47 PM.png
Custom Actions - show object name
Martin Koob
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
 
Posts: 216
Joined: Sun May 27, 2007 8:19 pm

Re: lcVCS problem

Postby jim1001 » Sat Jul 09, 2016 1:23 pm

Martin - just to be clear, the "lcvcs" script you use in your SourceTree custom control is one you have written yourself?

I created a new button in my UI to test the version control was working and this generated a new untracked file in the export. I think this is expected behaviour. I also got some false positives - not sure why as I didn’t do anything else to my knowledge. Can anyone explain the lcVCSExport a bit more than in section “Reducing false positives” here https://github.com/montegoulding/lcVCS ?

In the same section I don’t understand what “the message is sent to every object the objects in the lower parts of the message heirarchy will recieve it multiple times” is getting at.

Thanks for help.
jim1001
 
Posts: 98
Joined: Fri Jan 29, 2016 6:25 pm

Re: lcVCS problem

Postby jim1001 » Tue Jul 12, 2016 12:19 pm

Any help appreciated in answer to my last post of Sat July 09.

Thanks!
Jim
jim1001
 
Posts: 98
Joined: Fri Jan 29, 2016 6:25 pm

Re: lcVCS problem

Postby monte » Wed Jul 13, 2016 4:56 am

Hi Jim

Martin has access to a lcvcs command line app that I haven't released publicly just yet so that's what he was talking about. In regards to your actual question then you need to use lcVCSExport to clear out anything from your stack that you don't want to change. Imagine a stack with a resizeStack handler that sets the rect of 100 objects. You don't actually want to commit the changed rects of the objects each time. What you want to do is set the rect of the stack to a standard/default rect so that all the object rects are always the same. Then if one changes it should be a result of a deliberate change rather than accidental. The same goes for text you enter in a field to test something or controls you show and hide. If your lcVCSExport handlers are good enough then when you import a stack, make a change and then export the only diff you will see is intentional changes. Having said that though your vcs tools should allow you to commit just some changed files or even just some parts of a changed file.

FWIW I recommend using script only stacks as much as possible for your libraries and behaviors then using lcVCS just for UI if you can. I've actually written a small library which saves a UI layout for a script only stack in a simple readable format and doesn't support all the things that make lcVCS complicated as an intermediary between script only stacks and lcVCS. I would also recommend avoiding substacks in favour of single stack stackFiles as that at least gives you a bit more context on the diff. I am not entirely happy with lcVCS as my goal when implementing it was to support VCS for LiveCode with as few implementation restrictions as possible. I think if I limited the scope of lcVCS I could come up with something easier to use:

- no support for embedded images (must be referenced)
- possibly no support for custom property saving (must set at runtime)
- no support for anything requiring an ID so icons, patterns and behavior buttons must all be set in script using name references. Behavior stacks could be supported.
- all objects and their properties saved into a single file

People would still need to use lcVCSExport handlers to clean out session state.

Cheers

Monte
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
 
Posts: 1557
Joined: Fri Jan 13, 2012 1:47 am

Re: lcVCS problem

Postby jim1001 » Wed Jul 13, 2016 6:37 pm

Monte,

Thanks for your reply and trying to explain it - much appreciated. I’m afraid it hasn’t clicked yet though. Maybe it would be better if I asked more specific questions.

Martin has access to a lcvcs command line app that I haven't released publicly just yet so that's what he was talking about.


OK - thanks. Understood this bit!

In regards to your actual question then you need to use lcVCSExport to clear out anything from your stack that you don't want to change.

If your lcVCSExport handlers are good enough then when you import a stack, make a change and then export the only diff you will see is intentional changes.


Do you have to code a separate lcVCSExport handler for every object that may generate false positives?
If so then that handler needs to be different for each object?

When you say on the lcVCS GitHub page that
In any control that has a child control you will want to script your lcVCSExport handler like this

Code: Select all
on lcVCSExport
    if the target is not me then exit lcVCSExport
end lcVCSExport


Is that all the code that’s needed or is that just part of it?
Do you mean that by including this code in the parent object there will be no false positives generated by child objects?

FWIW I recommend using script only stacks as much as possible for your libraries and behaviors then using lcVCS just for UI if you can.

So far I’ve only created single stack .livecode files (everything rolled into one) and have used the Livecode GUI to create the UIs.
Can you point me somewhere to read about splitting into libraries, behaviours and UIs?
Are you saying that lcVCS shouldn’t be used for script-only library / behaviour stacks? I thought version control would be better tracking at LiveCode scripts than UIs...

- all objects and their properties saved into a single file

How do you do this?

Sorry for so many questions but hopefully by answering one or two the rest will fall into place :-)
Maybe you could supply a very basic example stack with some lcVCSExport handlers?

Thanks for your time,
Jim
jim1001
 
Posts: 98
Joined: Fri Jan 29, 2016 6:25 pm

Re: lcVCS problem

Postby monte » Mon Jul 18, 2016 4:42 am

Do you have to code a separate lcVCSExport handler for every object that may generate false positives?
If so then that handler needs to be different for each object?


In practical terms I generally find you can do what needs to be done in stack and/or card handlers. For example, if you have a resizeStack handler then in a stack lcVCSExport handler you can set the rect of the stack and that should in turn run the resizeStack handler and all your objects will be set to their standard rects. For example:

Code: Select all
on lcVCSExport
    if the target is not me then exit lcVCSExport
    set the rect of me to 100,500,100,800 -- 400x600
    set the text of field "Name" of me to empty
    -- and so on until anything that isn't meant to be saved is cleared
end lcVCSExport


So far I’ve only created single stack .livecode files (everything rolled into one) and have used the Livecode GUI to create the UIs.
Can you point me somewhere to read about splitting into libraries, behaviours and UIs?


I would start with the dictionary entries for `start using stack`, `insert script` & `behavior`. I believe there's also some info about the message path in the LiveCode Script guide.

Are you saying that lcVCS shouldn’t be used for script-only library / behaviour stacks? I thought version control would be better tracking at LiveCode scripts than UIs...


It's not necessary as script only stacks are just a text file with a script (no object properties etc).
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
 
Posts: 1557
Joined: Fri Jan 13, 2012 1:47 am

Re: lcVCS problem

Postby jim1001 » Fri Jul 22, 2016 11:20 am

Hi Monte,

Thanks for your reply.

For example, if you have a resizeStack handler then in a stack lcVCSExport handler you can set the rect of the stack and that should in turn run the resizeStack handler and all your objects will be set to their standard rects.


Thanks for the example & advice.

I would start with the dictionary entries for `start using stack`, `insert script` & `behavior`. I believe there's also some info about the message path in the LiveCode Script guide.


Thanks, yes I've done a bit more reading on this. Also found a helpful page on libraries at Brigham Young University: http://revolution.byu.edu/messages/libraries.php

It's not necessary as script only stacks are just a text file with a script (no object properties etc).


Ha - that's true. If they are already text files then version control will work fine on them already - no need for conversion by lcVCS. Silly me.

Best wishes,
Jim
jim1001
 
Posts: 98
Joined: Fri Jan 29, 2016 6:25 pm


Return to Version Control

Who is online

Users browsing this forum: No registered users and 1 guest

cron