Diff

[NewsArchive]

Hi Friedrich,

I was in holiday for two weeks and a colleague has done my job for this
time. Now I want to know, which changes was done to the setup script. My
first thougt was to copy the script as text and use an usual
diff-viewer, but unfortunately, the text does not show all parameters
(for example the exe name in the install service statement) and "copy
text" does not work for large scripts (about 3000 lines). But I'm sure,
you have a good idea.

Thanks for your help in advance.

Markus

[NewsArchive]

Hi Markus,

> I was in holiday for two weeks and a colleague has done my job for this
> time. Now I want to know, which changes was done to the setup script. My
> first thougt was to copy the script as text and use an usual diff-viewer,
> but unfortunately, the text does not show all parameters (for example the
> exe name in the install service statement) and "copy text" does not work
> for large scripts (about 3000 lines). But I'm sure, you have a good idea.

This is a good question. But unfortunately, I don't have a good idea on how
to handle this :-(

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder is Windows installation -- "point. click. ship"

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Perhaps you can implement a "save script as text" function in a future
Release. This should work for large scripts and should show all parameters.

Markus

[NewsArchive]

Markus,

> Perhaps you can implement a "save script as text" function in a future
> Release. This should work for large scripts and should show all
> parameters.

Good idea! We'll add this to the next build.

Thank you for your suggestion.

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder is Windows installation -- "point. click. ship"

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Great!

Greg Fasolt

[NewsArchive]

Cool

Jeff Slarve

[NewsArchive]

I'm still not very happy about this. At the moment, it is impossible to
compare to script versions effectifly. First it's not comfortable
because you have to load both versions in the ide and save them as text
and then use an other tool to compare and second you still don't see all
details. I would be really happy, if SB could save and load scripts in a
plain text format (XML for example), so I could compare two revisons in
our subversion client without loading them in the IDE.

Markus

[NewsArchive]

Hi Markus,

> I'm still not very happy about this. At the moment, it is impossible to
> compare to script versions effectifly. First it's not comfortable because
> you have to load both versions in the ide and save them as text and then
> use an other tool to compare and second you still don't see all details. I
> would be really happy, if SB could save and load scripts in a plain text
> format (XML for example), so I could compare two revisons in our
> subversion client without loading them in the IDE.

Yes, the current binary .sb7 format is suboptimal if you have to compare
scripts.

But it would definitely not be a trivial task to change the script format.
The currect solution works rock solid for 10+ years now and I am sure that a
switch to, say, XML would result in negative side-effects (and in a support
nightmare for use in the first few months <g>).

It is not set in stone, but I don't think that there will be a project
format change in SB8.

Friedrich

[NewsArchive]

Not switch - add!

The standard could leave in the binary format.

The new format should be an option (and could be declared as
experimental in SB8 with the target to have it in a stable state in
SB9). At the beginning, when this option is enabled, you can save
parallel in the old binary and the new text format (two different files)
to prevent undiscovered data loss.

Markus

[NewsArchive]

BTW: Rick Martin has posted a similar request on 18.12.2010 00:10

Markus

[NewsArchive]

Hi Marcus,

> Not switch - add!
>
> The standard could leave in the binary format.
>
> The new format should be an option (and could be declared as experimental
> in SB8 with the target to have it in a stable state in SB9). At the
> beginning, when this option is enabled, you can save parallel in the old
> binary and the new text format (two different files) to prevent
> undiscovered data loss.

In a perfect world, I am sure this would work.

But if it could be that easy <g>. The problem is that the underlying
"binary" script form is VERY complex. Quite a few different database tables
are involved (similar to a MSI SQL database structure). It's definitely not
a trivial task :-(

Friedrich

[NewsArchive]

Hi Friedrich,

I'll chime in here a bit. :)
I don't necessarily care to have a new format.
What I'd really like is two things:
1. option automate the export to text when the project is saved.
2. additional detail in the export text file.

That would give me what I'd like to see and I think cover some of Markus'
concerns.

Rick

[NewsArchive]

Hi Rick,

> I'll chime in here a bit. :)
> I don't necessarily care to have a new format.
> What I'd really like is two things:
> 1. option automate the export to text when the project is saved.
> 2. additional detail in the export text file.
>
> That would give me what I'd like to see and I think cover some of Markus'
> concerns.

Thank you for your feedback.

Of course, I see where you are coming. We eat our own dog food and also
have to compare (large) scripts on a regular basis (especially our Script
Writing Consulting). And the current solution is definitely "suboptimal".

We'll brainstorm it.

Thanks again,
Friedrich

[NewsArchive]

....I see where you are coming from...

Friedrich

[NewsArchive]

> ....I see where you are coming from...
>
> Friedrich

:D

[NewsArchive]

Hi Friedrich,

what is the result of your brainstorming?

Markus

[NewsArchive]

Hi Markus,

>
> what is the result of your brainstorming?
>

No development done on this and nothing planned (yet).

Friedrich