Multi-user question

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Multi-user question

Hans Persson-2
I wonder how GRAMPS will work when more than one person are working on
the same database. Both I and my father are interested in computerizing
our research into what is obviously the same family. I'd like us to be
able to work in a common database so that when I add something I want it
to be available to my father (after some kind of syncing) and vice
versa.

I don't know anything about the database storage and such of GRAMPS.
Perhaps I can export my database to GEDCOM when I'm done and simply
check the GEDCOM file into CVS. My father can then checkout the same
file and import into GRAMPS and have my updates. As long as we don't
update the same stuff at the same time, perhaps that is enough? I don't
know how feasible it would be to manually handle CVS conflicts in a
scenario like this (I'm sure one would happen sooner or later).

If I make a GEDCOM export, will absolutely everything from my database
be saved and later restored? That's a prerequisite for this to work,
obviously.

Is there a

Hans

--
+---------------------------------------------------------------------+
| Hans Persson                   http://pinkunicornblog.blogspot.com/ |
| [hidden email]         http://www.lysator.liu.se/~unicorn/  |
+---------------------------------------------------------------------+



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Multi-user question

bm-7
Hans,

GRAMPS is not made for simultaneous edit on  a gramps database.
You can locally, open a database two times, one for editing and one for
looking
though. So, indeed, for what you have in mind, CVS or subversion should be
used. I would go with subversion.

First, DO NOT USE GEDCOM, as not all information you can add in GRAMPS is
exported to GEDCOM (as GEDCOM is more limited in what it can store).

So, what you should do, is probably the following:

* same directory structure with you and your father, eg /home/genealogy
in which your images and such are installed. (You could make /home/genealogy a
symbolic link to /home/father/Documents/genea, ...). Perhaps consistently
working with relative paths for images/media objects might work, but my
experience is these things get mixed up.
* same GRAMPS version!! This is important, as different GRAMPS versions might
write output differently!
* same researcher information (this is the researcher tab in the preferences)
* After every editing session, export your database to the .gramps
format. (Work
with .grdb while editing, it is quicker, and saver (you have database
integrity)
* Untar the .gramps format, to obtain a *flat* text file.
* Add the flat text file .gramps to the SVN repository with 'svn commit' after
an editing session
* before editing, do 'svn up' to get the changes of your father.
   ==> if you DID NOT work on the same data, svn should be capable of merging
the changes. (I did not test it, YOU SHOULD TEST THIS FIRST!!)
   ==> if you get a conflict, you can open the two files in eg Kompare,
and look
at why it runs fool. The GRAMPS XML is very readable, and finding the problem
should not be too difficult (and will defenitely be much easier than comparing
GEDCOM). A tool like Kompare can make a diff/patch, which you can edit for the
problem areas.
   ==> However, some things will run bad: 1/GRAMPS ID might be double, eg, the
source you made will be S021, and the one your father made is S021.
This should
not be a problem however, as GRAMPS ID is something you need not work with if
you do not like it. In the preferences, you can moreover set the GRAMPS ID, so
you could have your father making ID's with FS..., and you CS..., ... with the
added bonus that afterward you are able to know who did what. 2/handles
(=intenal GRAMPS key for an object) should not coincide. The possibility of
creating a handle that is the same is less likely than winning the lottery, so
you should not worry about this I think.
* In GRAMPS, open AN EMPTY grdb, and do import of the .gramps file. Do your
editing...

The above should work. Please, if you try it, make a wiki page on
http://www.gramps-project.org/wiki to document your progress, and the problems
you encounter. It would help future discussion, and other users.

Once you have it running, you can do some feature requests at
http://bugs.gramps-project.org/ to remove some of the barriers. I think if you
go ahead with this, you might want:
* option to export to .gramps without it being compressed (so you can
do svn up
without first uncompressing the .gramps file)
* an easy way to set GRAMPS ID depending on the user (no idea, might work
already now, you should try playing with the preferences)
* support for multiple researchers (no idea, also this might actually already
work, you should give it a try. The problem I see is the researcher
list (to be
added in future version) getting longer and longer if researcher is not the
same)
* ...


Well, an interesting idea. I'm curious how it works out. Keep us informed.

Benny


Quoting Hans Persson <[hidden email]>:

> I wonder how GRAMPS will work when more than one person are working on
> the same database. Both I and my father are interested in computerizing
> our research into what is obviously the same family. I'd like us to be
> able to work in a common database so that when I add something I want it
> to be available to my father (after some kind of syncing) and vice
> versa.
>
> I don't know anything about the database storage and such of GRAMPS.
> Perhaps I can export my database to GEDCOM when I'm done and simply
> check the GEDCOM file into CVS. My father can then checkout the same
> file and import into GRAMPS and have my updates. As long as we don't
> update the same stuff at the same time, perhaps that is enough? I don't
> know how feasible it would be to manually handle CVS conflicts in a
> scenario like this (I'm sure one would happen sooner or later).
>
> If I make a GEDCOM export, will absolutely everything from my database
> be saved and later restored? That's a prerequisite for this to work,
> obviously.
>
> Is there a
>
> Hans
>
> --
> +---------------------------------------------------------------------+
> | Hans Persson                   http://pinkunicornblog.blogspot.com/ |
> | [hidden email]         http://www.lysator.liu.se/~unicorn/  |
> +---------------------------------------------------------------------+
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gramps-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Multi-user question

Douglas S. Blank
While Benny's suggestion will work, this is too complicated. We should
have some support for collaboration built-in to gramps. Some things that
would help:

- ability to list out all changes since a point in time
- ability to export these changes, maybe via the Spreadsheet export
- ability to easily merge a set of changes, marking conflicts

I don't think that this is "reinventing the wheel" just because some of
this functionality is in "diff" because it is at the wrong (too low)
level. We need higher-level tools. As more family members adopt gramps,
this kind of request will continue to grow, and we should have a good
infrastructure to build on.

What would we need that we don't currently have? A log of changes? Even if
a log just listed the objects (family or person) that changed, a
date/time, and optional comment, that might be enough.

-Doug

On Tue, March 13, 2007 10:01 am, [hidden email] wrote:

> Hans,
>
> GRAMPS is not made for simultaneous edit on  a gramps database.
> You can locally, open a database two times, one for editing and one for
> looking
> though. So, indeed, for what you have in mind, CVS or subversion should be
> used. I would go with subversion.
>
> First, DO NOT USE GEDCOM, as not all information you can add in GRAMPS is
> exported to GEDCOM (as GEDCOM is more limited in what it can store).
>
> So, what you should do, is probably the following:
>
> * same directory structure with you and your father, eg /home/genealogy
> in which your images and such are installed. (You could make
> /home/genealogy a
> symbolic link to /home/father/Documents/genea, ...). Perhaps consistently
> working with relative paths for images/media objects might work, but my
> experience is these things get mixed up.
> * same GRAMPS version!! This is important, as different GRAMPS versions
> might
> write output differently!
> * same researcher information (this is the researcher tab in the
> preferences)
> * After every editing session, export your database to the .gramps
> format. (Work
> with .grdb while editing, it is quicker, and saver (you have database
> integrity)
> * Untar the .gramps format, to obtain a *flat* text file.
> * Add the flat text file .gramps to the SVN repository with 'svn commit'
> after
> an editing session
> * before editing, do 'svn up' to get the changes of your father.
>    ==> if you DID NOT work on the same data, svn should be capable of
> merging
> the changes. (I did not test it, YOU SHOULD TEST THIS FIRST!!)
>    ==> if you get a conflict, you can open the two files in eg Kompare,
> and look
> at why it runs fool. The GRAMPS XML is very readable, and finding the
> problem
> should not be too difficult (and will defenitely be much easier than
> comparing
> GEDCOM). A tool like Kompare can make a diff/patch, which you can edit for
> the
> problem areas.
>    ==> However, some things will run bad: 1/GRAMPS ID might be double, eg,
> the
> source you made will be S021, and the one your father made is S021.
> This should
> not be a problem however, as GRAMPS ID is something you need not work with
> if
> you do not like it. In the preferences, you can moreover set the GRAMPS
> ID, so
> you could have your father making ID's with FS..., and you CS..., ... with
> the
> added bonus that afterward you are able to know who did what. 2/handles
> (=intenal GRAMPS key for an object) should not coincide. The possibility
> of
> creating a handle that is the same is less likely than winning the
> lottery, so
> you should not worry about this I think.
> * In GRAMPS, open AN EMPTY grdb, and do import of the .gramps file. Do
> your
> editing...
>
> The above should work. Please, if you try it, make a wiki page on
> http://www.gramps-project.org/wiki to document your progress, and the
> problems
> you encounter. It would help future discussion, and other users.
>
> Once you have it running, you can do some feature requests at
> http://bugs.gramps-project.org/ to remove some of the barriers. I think if
> you
> go ahead with this, you might want:
> * option to export to .gramps without it being compressed (so you can
> do svn up
> without first uncompressing the .gramps file)
> * an easy way to set GRAMPS ID depending on the user (no idea, might work
> already now, you should try playing with the preferences)
> * support for multiple researchers (no idea, also this might actually
> already
> work, you should give it a try. The problem I see is the researcher
> list (to be
> added in future version) getting longer and longer if researcher is not
> the
> same)
> * ...
>
>
> Well, an interesting idea. I'm curious how it works out. Keep us informed.
>
> Benny
>
>
> Quoting Hans Persson <[hidden email]>:
>
>> I wonder how GRAMPS will work when more than one person are working on
>> the same database. Both I and my father are interested in computerizing
>> our research into what is obviously the same family. I'd like us to be
>> able to work in a common database so that when I add something I want it
>> to be available to my father (after some kind of syncing) and vice
>> versa.
>>
>> I don't know anything about the database storage and such of GRAMPS.
>> Perhaps I can export my database to GEDCOM when I'm done and simply
>> check the GEDCOM file into CVS. My father can then checkout the same
>> file and import into GRAMPS and have my updates. As long as we don't
>> update the same stuff at the same time, perhaps that is enough? I don't
>> know how feasible it would be to manually handle CVS conflicts in a
>> scenario like this (I'm sure one would happen sooner or later).
>>
>> If I make a GEDCOM export, will absolutely everything from my database
>> be saved and later restored? That's a prerequisite for this to work,
>> obviously.
>>
>> Is there a
>>
>> Hans
>>
>> --
>> +---------------------------------------------------------------------+
>> | Hans Persson                   http://pinkunicornblog.blogspot.com/ |
>> | [hidden email]         http://www.lysator.liu.se/~unicorn/  |
>> +---------------------------------------------------------------------+
>>
>>
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share
>> your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Gramps-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-users
>>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gramps-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users
>


--
Douglas S. Blank
Associate Professor, Bryn Mawr College
http://cs.brynmawr.edu/~dblank/
Office: 610 526 6501

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Multi-user question

Gerald Britton-2
Hans' problem is not too different from my own.  I regularly edit my
data from two computers.  Here's what I do:

- Both computers have the same directory structure under gramps:

gramps
gramps/media

- On computer 1, I do some editing, maybe add/delete/udpate media
files, whatever.

- When I'm done, I backup the database to gramps xml format in the
gramps subdir, then rsync the directory structure (rsync -ruv gramps
me@computer2:/gramps)

- on computer 2, I open the backup I created on computer 1, save it
over my grdb, and continue.

- If I make changes on computer 2, I follow the same procedure

On 3/13/07, Douglas S. Blank <[hidden email]> wrote:

> While Benny's suggestion will work, this is too complicated. We should
> have some support for collaboration built-in to gramps. Some things that
> would help:
>
> - ability to list out all changes since a point in time
> - ability to export these changes, maybe via the Spreadsheet export
> - ability to easily merge a set of changes, marking conflicts
>
> I don't think that this is "reinventing the wheel" just because some of
> this functionality is in "diff" because it is at the wrong (too low)
> level. We need higher-level tools. As more family members adopt gramps,
> this kind of request will continue to grow, and we should have a good
> infrastructure to build on.
>
> What would we need that we don't currently have? A log of changes? Even if
> a log just listed the objects (family or person) that changed, a
> date/time, and optional comment, that might be enough.
>
> -Doug
>
> On Tue, March 13, 2007 10:01 am, [hidden email] wrote:
> > Hans,
> >
> > GRAMPS is not made for simultaneous edit on  a gramps database.
> > You can locally, open a database two times, one for editing and one for
> > looking
> > though. So, indeed, for what you have in mind, CVS or subversion should be
> > used. I would go with subversion.
> >
> > First, DO NOT USE GEDCOM, as not all information you can add in GRAMPS is
> > exported to GEDCOM (as GEDCOM is more limited in what it can store).
> >
> > So, what you should do, is probably the following:
> >
> > * same directory structure with you and your father, eg /home/genealogy
> > in which your images and such are installed. (You could make
> > /home/genealogy a
> > symbolic link to /home/father/Documents/genea, ...). Perhaps consistently
> > working with relative paths for images/media objects might work, but my
> > experience is these things get mixed up.
> > * same GRAMPS version!! This is important, as different GRAMPS versions
> > might
> > write output differently!
> > * same researcher information (this is the researcher tab in the
> > preferences)
> > * After every editing session, export your database to the .gramps
> > format. (Work
> > with .grdb while editing, it is quicker, and saver (you have database
> > integrity)
> > * Untar the .gramps format, to obtain a *flat* text file.
> > * Add the flat text file .gramps to the SVN repository with 'svn commit'
> > after
> > an editing session
> > * before editing, do 'svn up' to get the changes of your father.
> >    ==> if you DID NOT work on the same data, svn should be capable of
> > merging
> > the changes. (I did not test it, YOU SHOULD TEST THIS FIRST!!)
> >    ==> if you get a conflict, you can open the two files in eg Kompare,
> > and look
> > at why it runs fool. The GRAMPS XML is very readable, and finding the
> > problem
> > should not be too difficult (and will defenitely be much easier than
> > comparing
> > GEDCOM). A tool like Kompare can make a diff/patch, which you can edit for
> > the
> > problem areas.
> >    ==> However, some things will run bad: 1/GRAMPS ID might be double, eg,
> > the
> > source you made will be S021, and the one your father made is S021.
> > This should
> > not be a problem however, as GRAMPS ID is something you need not work with
> > if
> > you do not like it. In the preferences, you can moreover set the GRAMPS
> > ID, so
> > you could have your father making ID's with FS..., and you CS..., ... with
> > the
> > added bonus that afterward you are able to know who did what. 2/handles
> > (=intenal GRAMPS key for an object) should not coincide. The possibility
> > of
> > creating a handle that is the same is less likely than winning the
> > lottery, so
> > you should not worry about this I think.
> > * In GRAMPS, open AN EMPTY grdb, and do import of the .gramps file. Do
> > your
> > editing...
> >
> > The above should work. Please, if you try it, make a wiki page on
> > http://www.gramps-project.org/wiki to document your progress, and the
> > problems
> > you encounter. It would help future discussion, and other users.
> >
> > Once you have it running, you can do some feature requests at
> > http://bugs.gramps-project.org/ to remove some of the barriers. I think if
> > you
> > go ahead with this, you might want:
> > * option to export to .gramps without it being compressed (so you can
> > do svn up
> > without first uncompressing the .gramps file)
> > * an easy way to set GRAMPS ID depending on the user (no idea, might work
> > already now, you should try playing with the preferences)
> > * support for multiple researchers (no idea, also this might actually
> > already
> > work, you should give it a try. The problem I see is the researcher
> > list (to be
> > added in future version) getting longer and longer if researcher is not
> > the
> > same)
> > * ...
> >
> >
> > Well, an interesting idea. I'm curious how it works out. Keep us informed.
> >
> > Benny
> >
> >
> > Quoting Hans Persson <[hidden email]>:
> >
> >> I wonder how GRAMPS will work when more than one person are working on
> >> the same database. Both I and my father are interested in computerizing
> >> our research into what is obviously the same family. I'd like us to be
> >> able to work in a common database so that when I add something I want it
> >> to be available to my father (after some kind of syncing) and vice
> >> versa.
> >>
> >> I don't know anything about the database storage and such of GRAMPS.
> >> Perhaps I can export my database to GEDCOM when I'm done and simply
> >> check the GEDCOM file into CVS. My father can then checkout the same
> >> file and import into GRAMPS and have my updates. As long as we don't
> >> update the same stuff at the same time, perhaps that is enough? I don't
> >> know how feasible it would be to manually handle CVS conflicts in a
> >> scenario like this (I'm sure one would happen sooner or later).
> >>
> >> If I make a GEDCOM export, will absolutely everything from my database
> >> be saved and later restored? That's a prerequisite for this to work,
> >> obviously.
> >>
> >> Is there a
> >>
> >> Hans
> >>
> >> --
> >> +---------------------------------------------------------------------+
> >> | Hans Persson                   http://pinkunicornblog.blogspot.com/ |
> >> | [hidden email]         http://www.lysator.liu.se/~unicorn/  |
> >> +---------------------------------------------------------------------+
> >>
> >>
> >>
> >> -------------------------------------------------------------------------
> >> Take Surveys. Earn Cash. Influence the Future of IT
> >> Join SourceForge.net's Techsay panel and you'll get the chance to share
> >> your
> >> opinions on IT & business topics through brief surveys-and earn cash
> >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >> _______________________________________________
> >> Gramps-users mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/gramps-users
> >>
> >
> >
> >
> > ----------------------------------------------------------------
> > This message was sent using IMP, the Internet Messaging Program.
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Gramps-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/gramps-users
> >
>
>
> --
> Douglas S. Blank
> Associate Professor, Bryn Mawr College
> http://cs.brynmawr.edu/~dblank/
> Office: 610 526 6501
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gramps-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Multi-user question

Alex Roitman
In reply to this post by bm-7
On Tue, 2007-03-13 at 15:01 +0100, [hidden email] wrote:
> * Untar the .gramps format, to obtain a *flat* text file.

.gramps is already flat, it just is compressed. gunzip is
what you need.

Alex

--
Alexander Roitman   http://www.gramps-project.org


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Multi-user question

bm-7
In reply to this post by Douglas S. Blank
Doug,

what I propose works now. What you would like is today on nobody's todo list.
GRAMPS is meant as a local genealogy application.
Collaborative applications exist (eg. phpgedview).

The need for working independently and merging back in changes, exists in both
these types of applications (eg in phpgedview you keep a local copy on a
laptop, and want to merge it back it). However, merging is extremely
complicated! Building support for that would be very time consuming,
error-prone, and technically difficult for a normal user to grasp.
I think tools like CVS and SVN are specifically made for this: they merge
automatically in the easy cases, or they conflict and you need to solve
it. The
lowest level of support, without coding effort

> While Benny's suggestion will work, this is too complicated. We should
> have some support for collaboration built-in to gramps. Some things that
> would help:
>
> - ability to list out all changes since a point in time

I don't know the checkpoint tool, but I suppose you could use it for that. You
set timestamps and can get the state of the database at that time. The
difference is then a diff away.

> - ability to export these changes, maybe via the Spreadsheet export

Actually, a diff made with svn would do this. As .gramps is .xml, this diff
would actually be quite readable. You cannot just export changes as complete
records, so export to spreadsheet is not an option. You need to keep changes
attribute wise, but that would be hellish with batch changes (log overflowing,
...).

> - ability to easily merge a set of changes, marking conflicts

and this is the complicated part...

[snip]

Let's not foul ourselves, for collaborative work, tools like phpgedview can be
used. A solution of exporting and merging will *never* be a good solution,
because it is just too complicated, and would need constant maintenance with
every little change. This would seriously hinder the development of GRAMPS in
the goal of GRAMPS: a professional local genealogy application.

As a thought exercise, what would be needed:
1/keeping in database the complete database log, and be able to write it out,
one change at a time.
2/comparing changes from two databases, making a new log file, asking user
intervention on conflicts
3/reading in a change log, roll back to beginning, and do all the changes
according to the new log
In short, you need a database level control, however, only one of the file
structures of gramps is a database.
 From the above, it should be clear GRAMPS is a long way from being able to
implement this kind of thing. Any in between solution which would partially
work if you know what you are doing, is not option, as this cannot be required
from the average user.

Benny

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Multi-user question

Duncan Lithgow-2
In reply to this post by Hans Persson-2
I think that GRAMPS is just the wrong app for what you want to do. I
understand what you want to do and I've wondered about doing it myself,
I thought it might encourage others to work with me on the data.

Benny mentions PhpGedview. I'd say that's the way to go. I've had a play
with it and it's a perfectly good application. I suspect that after you
and your father have got most of the basic data in you can think about
switching from PhpGedview to a local program like GRAMPS. I think you're
risking some unfortunate data loss if you try and go multi-use now.

Just my opinion,

Duncan

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Multi-user question

Eero Tamminen-3
In reply to this post by bm-7
Hi,

On Tuesday 13 March 2007 16:01, [hidden email] wrote:

> * before editing, do 'svn up' to get the changes of your father.
>    ==> if you DID NOT work on the same data, svn should be capable of
> merging the changes. (I did not test it, YOU SHOULD TEST THIS FIRST!!)
>    ==> if you get a conflict, you can open the two files in eg Kompare,
> and look
> at why it runs fool. The GRAMPS XML is very readable, and finding the
> problem should not be too difficult (and will defenitely be much easier
> than comparing GEDCOM). A tool like Kompare can make a diff/patch, which
> you can edit for the problem areas.
>    ==> However, some things will run bad: 1/GRAMPS ID might be double,
> eg, the source you made will be S021, and the one your father made is
> S021. This should
> not be a problem however, as GRAMPS ID is something you need not work
> with if you do not like it. In the preferences, you can moreover set the
> GRAMPS ID, so you could have your father making ID's with FS..., and you
> CS..., ... with the added bonus that afterward you are able to know who
> did what. 2/handles (=intenal GRAMPS key for an object) should not
> coincide. The possibility of creating a handle that is the same is less
> likely than winning the lottery, so you should not worry about this I
> think.
> * In GRAMPS, open AN EMPTY grdb, and do import of the .gramps file. Do
> your editing...

Are you seriously suggesting that aunt Martha (or somebody's father)
would really put up with something like this?

I could image doing an XML-conflict merge by hand once, but that would
be the last time I use program requiring it...  I've been reading diffs of
Gramps XML exports before commiting them into version control and those
diffs are not really something that you would like to resolve at the low
level (you can have conflicts at different levels of the data, with
references etc).


        - Eero

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Multi-user question

bm-7
Quoting Eero Tamminen <[hidden email]>:

> Hi,
>
> On Tuesday 13 March 2007 16:01, [hidden email] wrote:
>> * before editing, do 'svn up' to get the changes of your father.
>>    ==> if you DID NOT work on the same data, svn should be capable of
>> merging the changes. (I did not test it, YOU SHOULD TEST THIS FIRST!!)
>>    ==> if you get a conflict, you can open the two files in eg Kompare,
>> and look
>> at why it runs fool. The GRAMPS XML is very readable, and finding the
>> problem should not be too difficult (and will defenitely be much easier
>> than comparing GEDCOM). A tool like Kompare can make a diff/patch, which
>> you can edit for the problem areas.
>>    ==> However, some things will run bad: 1/GRAMPS ID might be double,
>> eg, the source you made will be S021, and the one your father made is
>> S021. This should
>> not be a problem however, as GRAMPS ID is something you need not work
>> with if you do not like it. In the preferences, you can moreover set the
>> GRAMPS ID, so you could have your father making ID's with FS..., and you
>> CS..., ... with the added bonus that afterward you are able to know who
>> did what. 2/handles (=intenal GRAMPS key for an object) should not
>> coincide. The possibility of creating a handle that is the same is less
>> likely than winning the lottery, so you should not worry about this I
>> think.
>> * In GRAMPS, open AN EMPTY grdb, and do import of the .gramps file. Do
>> your editing...
>
> Are you seriously suggesting that aunt Martha (or somebody's father)
> would really put up with something like this?
>
> I could image doing an XML-conflict merge by hand once, but that would
> be the last time I use program requiring it...  I've been reading diffs of
> Gramps XML exports before commiting them into version control and those
> diffs are not really something that you would like to resolve at the low
> level (you can have conflicts at different levels of the data, with
> references etc).

Two people working offline on the same data. Is there another option than to
merge it?

B.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Multi-user question

Joachim Breitner
Hi,

Am Sonntag, den 25.03.2007, 22:07 +0200 schrieb
[hidden email]:
> Two people working offline on the same data. Is there another option than to
> merge it?

Theoretically, both versions could write a machine readable change log.
Then, upon mergin, you would not have to merge the data, but the
changes, where it is (relatively) easy to identify independent changes
and to ask intelligent questions in case of conflicting changes.

But it would be a lot of work to implement.

Greetings,
Joachim
--
Joachim Breitner
  e-Mail: [hidden email]
  Homepage: http://www.joachim-breitner.de
  ICQ#: 74513189

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users