Sounds like good news. I will keep submitting patches until you decide
to grant SVN access. :)
@Stefan
Yes, I already worked with SVN and git. You can have a look at my ohloh
[1] and github [2] accounts if you like to. Yet before I never got
involved in Open Source development without direct linking to my
institute (ifgi) or work.
So this is where I try to get more used to and more experienced with. If
you want to add me as project member, sure that would be very nice.
@Ede
I think comparing the old project location with the new project location
is a good idea, but do we really need another dialog, as the user is
asked about broken layers already?
Rather I would foster automatic behavior for more better usability.
I got two new Ideas on how to preserve relative location without the
downwards-compatibility problem.
They should both have same effects. I would prefer solution 2, but maybe
you'll find the first one more appealing.
1. Deriving possible projectfile-resource relations by comparing the old
project location with the new location:
old location and resource:
* c:/projects/*myProject.jml
* c:/projects/*mydata/data.jml
open project in new location:
* d:/workspace/*myProject.jml (given)
--> *d:/workspace/*mydata/data.jml (update)
2. Storing relative paths in a different resource property, e.g.
"File_Relative_Location_Hint". They are used to updade the absolute path
if the project was moved or copied together with the data.
It will not affect the behavior of older version of OJ because the
absolute location are kept and the location hint-property is never
evaluated.
Further I'd suggest the following workflow:
1. Check if the project was moved; if true 2, if false 4
2. Try to update paths based on relative location; if resources do not
exist 3
3. Check if resources exist denoted by the absolute path; if true update
location hint, if false 4
4. Ask user to select resources manually, that has not been found, if
any. (this is the feature that we already have)
A more user-informed approach might be to prompt a table at step 4, were
all (broken) layers are listed and also the detected matching files, if any.
The user can either approve everything or choose different locations for
selected layers. I do not think that this is necessary, but possibly a
nice-to-have.
Please let me know about your preferences.
I will work in parallel on the Project-Archives (*.jmz) suggested in the
user-list discussion, but keep it as a separate contribution (patch).
Matthias
[1] http://www.ohloh.net/accounts/MatthiasHinz
[2] https://github.com/MatthiasHinz
Am 07.09.2013 00:19, schrieb edgar.sol...@web.de:
On 06.09.2013 23:40, Stefan Steiniger wrote:
If you think you keep contributing the svn write access rules are as
follows:
You would have to send two code contribution/patches (one you sent
already). And if both are approved, then we could give you write access
to the SVN. Alternatively, someone else who knows already your skills
can speak up for you and we would give you straight write access (this
happened too). I think these rules are a fairly low barrier, and we are
always happy if someone is willing to contribute.
i am a little reluctant to assign write access right away. let's see how the
commitment develops. for the time being i have no problem with reviewing
patches and committing them manually when approved.
should this develop into to much trouble because of extended commitment it'll
be easy to grant commit access and an informed decision :)
wrt. to the issue.. sounds good so far. but the IndexOutOfBoundsException is
not acceptable. i'd suggest the following workflow which i know works well for
a software i use periodically. i know it does not use relative paths, but the
result is quite similar.
saving
1. keep absolute paths during saving
2. save the absolute path to the project file, if not already saved, as an
extra value
opening
1. compare saved project path with actual project path
if they differ
1.1. open a dialog informing the user that the project has moved and offer to
update
a. all data file paths
b. only data file paths for which the data is not available in it's old
path
how does that sound? i could live with only 1.1.a as well for now. but 1.1.b
sounds like a cheap addition while were on it.
nice that your tackling it :)..ede
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
