Hi Alaska dev team,

how do you plan to support version control systems if user specific
settings like the currently opened files are stored in the project file?

In our current scenario at Wegasoft, we also store the xpj files via Visual
SourceSafe.

So if the currently opened files are stored in the XPJ file, I can't use
VSS to interchange xpj files between developers, because I will always
influence others current files list. So there would be no way to use VX in
this case.

IMO settings like this should be stored outside the project file (ini file,
XML file... whatever you like 

Thomas

Xbase++ FAQ : www.software-braun.de/xbfaq/xbfaq.htm
But then you could make ANY word derogatory by INTENDING it to be.
(Say the word "cabbage" and it stirs no emotion:glare at somebody
and throw in an expletive or two  and it's bound to offend people.)
		-- from alt.appalachian

Hi Thomas,

"Thomas Braun" <spam@software-braun.de> schrieb im Newsbeitrag
news:XrJ9ddh2DHA.2012@S15147418...
> Hi Alaska dev team,
>
> how do you plan to support version control systems if user specific
> settings like the currently opened files are stored in the project file?
>
> In our current scenario at Wegasoft, we also store the xpj files via
Visual
> SourceSafe.
>
> So if the currently opened files are stored in the XPJ file, I can't use
> VSS to interchange xpj files between developers, because I will always
> influence others current files list. So there would be no way to use VX in
> this case.
>
> IMO settings like this should be stored outside the project file (ini
file,
> XML file... whatever you like 

This is a good question. This first needs that VX is able to know each
developper working on the project. So each develloper has to have a unique
number or key or something else handled within VX. The next step is to have
sections within the XPJ-file starting with the developpers unique key and
within these sections VX can store developper specific informations like
last opened files.
HTH
Klemens

Klemens Lichter:

> This is a good question. This first needs that VX is able to know each
> developper working on the project. So each develloper has to have a unique
> number or key or something else handled within VX.

VSS manages the settings via the machine name in a separate ini file.

> The next step is to have
> sections within the XPJ-file starting with the developpers unique key and
> within these sections VX can store developper specific informations like
> last opened files.

IMHO, this kind of information should not be stored inside the project
file. It only bloats the file and makes a diff via VSS impossible (to see
the changes made by any developer).

I think designing the IDE without having developer teams and source
management software in mind may cause bigger changes to VX in the future.

What IMO is needed is:

Storing editor states (and maybe other information that does not belong
into the project file) per machine and project in a location on each local
machine (preferably not the registry )

Thomas Braun

"Thomas Braun" <spam@wegasoft.de> schrieb im Newsbeitrag
news:z7txisugd0tb.jm0x1beb9dg4.dlg@40tude.net...
> Klemens Lichter:
>
> > This is a good question. This first needs that VX is able to know each
> > developper working on the project. So each develloper has to have a
unique
> > number or key or something else handled within VX.
>
> VSS manages the settings via the machine name in a separate ini file.

OK this is anoter good way.

> > The next step is to have
> > sections within the XPJ-file starting with the developpers unique key
and
> > within these sections VX can store developper specific informations like
> > last opened files.
>
> IMHO, this kind of information should not be stored inside the project
> file. It only bloats the file and makes a diff via VSS impossible (to see
> the changes made by any developer).
>
> I think designing the IDE without having developer teams and source
> management software in mind may cause bigger changes to VX in the future.
>
> What IMO is needed is:
>
> Storing editor states (and maybe other information that does not belong
> into the project file) per machine and project in a location on each local
> machine (preferably not the registry )

OK, storing in a sort of INI file or maybe not XPJ but XPU ( [X]base
[P]roject [U]sersettings) is a way. But why storing on local disk? Storing
within the projects directorystructure makes it easy to save together with
source etc. I hate local savings of settings belonging to projects that
store oll their other data in  shared network drives. Local settings are
good for to tell VX or other Programms where to find the projects files when
VX is started on this specific PC, but all other data containing to a
project have to be stored there.
But OK, in VX there are so many things configurable, so why not make this
configurable too.

Klemens

Hi All,

We at Alaska use the CVS and we have observed exactly the same issues
you describe.

I currently use a work around and remove all individual settings from
the project prior checking it into the repository.
This way I have realized that there are differences with the xpj file
in very rare cases. The first difference pops up when a project is
saved for the first time by vx, since  target handling is a bit
different then with pbuild (allthough they are compatible). Any further
difference result from an added or removed file (practically this
is not the case very often).

Like I said, this requires investigation what the real differences are 
with the project.

We are not happy with this situation either, BUT:


    The VX is currently not said to have dev team capabilities.


Currently we do not know the best way to solve the issues that come with 
many people access the same thing. What we know is:

   o Registry is a bad dream, somehow.
   o Having all personell settings in the project file is a good
     solution (for one man dev teams).
   o We need more then one personal setting for a project
     ( for example to have different groups of breakpoints )
   o Settings located in another place then the project file
     is an idea I do not like (You are free to discuss this).
   o We need integration to version control systems.

Regards
   Andreas Herdt
   [Alaska Research & Development]

Klemens Lichter wrote:

> "Thomas Braun" <spam@wegasoft.de> schrieb im Newsbeitrag
> news:z7txisugd0tb.jm0x1beb9dg4.dlg@40tude.net...
> 
>>Klemens Lichter:
>>
>>
>>>This is a good question. This first needs that VX is able to know each
>>>developper working on the project. So each develloper has to have a
> 
> unique
> 
>>>number or key or something else handled within VX.
>>
>>VSS manages the settings via the machine name in a separate ini file.
> 
> 
> OK this is anoter good way.
> 
> 
>>>The next step is to have
>>>sections within the XPJ-file starting with the developpers unique key
> 
> and
> 
>>>within these sections VX can store developper specific informations like
>>>last opened files.
>>
>>IMHO, this kind of information should not be stored inside the project
>>file. It only bloats the file and makes a diff via VSS impossible (to see
>>the changes made by any developer).
>>
>>I think designing the IDE without having developer teams and source
>>management software in mind may cause bigger changes to VX in the future.
>>
>>What IMO is needed is:
>>
>>Storing editor states (and maybe other information that does not belong
>>into the project file) per machine and project in a location on each local
>>machine (preferably *not* the registry <g>)
> 
> 
> OK, storing in a sort of INI file or maybe not XPJ but XPU ( [X]base
> [P]roject [U]sersettings) is a way. But why storing on local disk? Storing
> within the projects directorystructure makes it easy to save together with
> source etc. I hate local savings of settings belonging to projects that
> store oll their other data in  shared network drives. Local settings are
> good for to tell VX or other Programms where to find the projects files when
> VX is started on this specific PC, but all other data containing to a
> project have to be stored there.
> But OK, in VX there are so many things configurable, so why not make this
> configurable too.
> 
> Klemens
> 
>

Hi All,

Just for notification:
This thread has just started some discussion at our place resulting
in a design meeting.

For next release we plan to have
   OPENFILES
   BREAKPOINT
   WATCHPOINT
   HOSTPROCESS
   RUNPARAM
   ...

stored in a different file then xpj.
Thus we have a clear seperation of what is a project and what is
a personel setting.

Hope that helps.

Regards
   Andreas Herdt
   [Alaska Research & Development]

Andreas Herdt wrote:

> Hi All,
> 
> We at Alaska use the CVS and we have observed exactly the same issues
> you describe.
> 
> I currently use a work around and remove all individual settings from
> the project prior checking it into the repository.
> This way I have realized that there are differences with the xpj file
> in very rare cases. The first difference pops up when a project is
> saved for the first time by vx, since  target handling is a bit
> different then with pbuild (allthough they are compatible). Any further
> difference result from an added or removed file (practically this
> is not the case very often).
> 
> Like I said, this requires investigation what the real differences are 
> with the project.
> 
> We are not happy with this situation either, BUT:
> 
> 
>    The VX is currently not said to have dev team capabilities.
> 
> 
> Currently we do not know the best way to solve the issues that come with 
> many people access the same thing. What we know is:
> 
>   o Registry is a bad dream, somehow.
>   o Having all personell settings in the project file is a good
>     solution (for one man dev teams).
>   o We need more then one personal setting for a project
>     ( for example to have different groups of breakpoints )
>   o Settings located in another place then the project file
>     is an idea I do not like (You are free to discuss this).
>   o We need integration to version control systems.
>

Andreas Herdt:

> We at Alaska use the CVS and we have observed exactly the same issues
> you describe.

Hehe, so at least you can feel with me 

> I currently use a work around and remove all individual settings from
> the project prior checking it into the repository.

Urghhhh... I wouldn't call this a "workaround", but rather a big PITA 

> We are not happy with this situation either, BUT:
>
>     The VX is currently not said to have dev team capabilities.



I remember the situation from my VO experiences, IIRC they needed the time
between 1.0 and 2.0 to deliver real dev team capabilities.

The situation is a bit different here because VX already has the open
plugin interface, so at least we can implement checkin/checkout
functionality from within the IDE quite fast.

But to be able to use this, the correct base logic (like the "files opened
in session" problem) must be settled before tu much other things depends on
the wrong way of doing things... each hour of planning time saves 10 hours
of changing the progam 

> Currently we do not know the best way to solve the issues that come with
> many people access the same thing. What we know is:
>
>    o Registry is a bad dream, somehow.

Yes, it *IS*. BTW, Multiedit doesn't use the registry for other purposes
than installation issues.

>    o We need more then one personal setting for a project
>      ( for example to have different groups of breakpoints )

Yes, IMO this can all be stored in a separate personal file in each
developers working dir (where the xpj file resides).

This way you can easily avoid checking personal file into the VCS.

>    o Settings located in another place then the project file
>      is an idea I do not like (You are free to discuss this).

I agree!

>    o We need integration to version control systems.

From my point of view, desperately 

The question is if going the Microsoft way (using their source control
provider interface) is the right way... does CVS or other systems support
this interface (or only Visual Sourcesafe)?

Thomas Braun

Klemens Lichter:

> OK, storing in a sort of INI file or maybe not XPJ but XPU ( [X]base
> [P]roject [U]sersettings) is a way. But why storing on local disk? Storing
> within the projects directorystructure makes it easy to save together with
> source etc.

My projectstructure resides on a local drive, so I can take work home (or
to a clients site).

The only storage for our sources that is on the server is the SourceSafe
database. Everything else is on each developers local drive (simply because
it is much faster doing a fulltext search or the compile/link cycle on a
local drive than a networked one...

> I hate local savings of settings belonging to projects that
> store oll their other data in  shared network drives.

Multiedit has status file that store all information per working dir and
you can choose where to store them and how to handle them.

I attach a small png screenshot what kind of settings you can have.

Thomas Braun

Klemens,

> This is a good question. This first needs that VX is able to know each
> developper working on the project. So each develloper has to have a unique
> number or key or something else handled within VX. The next step is to have
> sections within the XPJ-file starting with the developpers unique key and
> within these sections VX can store developper specific informations like
> last opened files.

Aaarrgghhh! NO!

The IDE should define a project directory (local) for storing workstation
specific info (e.g. which files were opened, which lines were current,
etc.)

The IDE should also specify a project directory (network) for shared files.

So a possible tree for a local-only system might look like this:

VX +
   +--Projects+
              +--MyProj+
              |        +LocalProj
              |        +NetworkProj
              +--AnotherProj+
                            +LocalProj
                            +NetworkProj

In a multi-develper env, NetworkProj should actually be on a network share.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

I want it all or nothing. Or maybe some.

I am not shure whether I've got the idea in detail,
so let me explain how I would do it (in a mannor that it can be done
for next revision):

There is one "Master Project File" in the project directory.
This file is maintained by VX and it has got a section for each project
that was opened in VX in the past and is still present when the VX is 
started up.

Let's say in ..\xppw32\projects\project.xpm (xbase project master 

[g:\source\test\bla\project.xpj]       project section
[test.exe]                             target section
   OPENFILES   = test.prg
   BREAKPOINT  = test.prg:1=1
   WATCHPOINT  = test.prg:MyFunc()
   HOSTPROCESS =
   RUNPARAM    = a b c d e f
[target\test3.dll]                     target section
   OPENFILES   = dllmain.prg,test.prg
   RECENTFILE  = dllmain.prg
   BREAKPOINT  = dllmain.prg:4=2
   WATCHPOINT  = test.prg:YourFunc()
   HOSTPROCESS = test.exe
   RUNPARAM    = g h i j k l m

[f:\test\project.xpj]                 project section
[test.exe]
   OPENFILES   = MyFile
   ...

Thus, what is shared between developers is the project file.
There the information resides what files belong to the project.

On the other hand, individual settings are collected at one location
per machine.

Would something like this fullfill your requirements?

Regards
   Andreas Herdt
   [Alaska Research & Development]

Phil Ide wrote:

> Klemens,
> 
> 
>>This is a good question. This first needs that VX is able to know each
>>developper working on the project. So each develloper has to have a unique
>>number or key or something else handled within VX. The next step is to have
>>sections within the XPJ-file starting with the developpers unique key and
>>within these sections VX can store developper specific informations like
>>last opened files.
> 
> 
> Aaarrgghhh! NO!
> 
> The IDE should define a project directory (local) for storing workstation
> specific info (e.g. which files were opened, which lines were current,
> etc.)
> 
> The IDE should also specify a project directory (network) for shared files.
> 
> So a possible tree for a local-only system might look like this:
> 
> VX +
>    +--Projects+
>               +--MyProj+
>               |        +LocalProj
>               |        +NetworkProj
>               +--AnotherProj+
>                             +LocalProj
>                             +NetworkProj
> 
> In a multi-develper env, NetworkProj should actually be on a network share.
> 
> Regards,

Andreas,

> Thus, what is shared between developers is the project file.
> There the information resides what files belong to the project.
> 
> On the other hand, individual settings are collected at one location
> per machine.
> 
> Would something like this fullfill your requirements?

Yes.

Regards,

Phil Ide

***************************************
* Xbase++ FAQ, Libraries and Sources: *
* goto: http://www.idep.org.uk/xbase  *
***************************************

Always forgive your enemies. They -HATE- that!