Re: [sqlite] splite database under version control (subversion)?

[Eduardo Morras]

At 23:19 04/05/2008, you wrote:

>If you use svn only to sync over many pc maybe you can put your project on a
>usb device (or usb hd) so you don't need to "sync" with svn.
>
>If you WANT to use svn and you are under linux you can create an alias for
>commit that make a dump of your db then commit it and one alias that update
>and read the dump in db.
>
>Maybe in windows you can make a batch, I don't know windows very well.

In windows you can change the extension to .sdb and windows will do 
all the work. Very slow, very risky but works


One reason that life is complex is that it has a real part and an 
imaginary part
-Andrew Koenig  

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] splite database under version control (subversion)?

[Jay A. Kreibich]

On Sun, May 04, 2008 at 10:36:47PM +0200, M. Emal Alekozai scratched on the 
wall:
> Hi,
> > In the BIG db I have worked on there is a table that log every insert/update
> > on specific and important tables and a log of every sql statement execute
> > but I haven't ever see a db under version control with svn (or csv or git or
> > any other).
>   
> I'm (mis)using subversion more as a synchronization tool than as a 
> version control system.

  You can mark the database files as binary, assuming you're only editing
  them in one location at a time.  Chances are Subversion will mark the
  database file as "binary" automatically, but you can also force
  Subversion to consider it binary by setting a non-text MIME type
  (such as "application/x-sqlite3").  See this FAQ question for more info:

  http://subversion.tigris.org/faq.html#binary-files

  Binary files are treated the same as any other file, except they
  cannot be merged.  This is only an issue if the file is edited in
  more than one source tree at the same time.  In this case, when the
  second source tree tries to do a commit, it will always return as a
  failed merge.

  You can also configure Subversion to require a lock on the file in
  order to edit it.  This makes editing even more restrictive, but also
  means you'll never have to deal with the merge issue.


  Don't be concerned about putting binary files into revision control
  systems.  Subversion handles this without problems, as do most other
  revision systems.  At my day job well over half the files in our
  project trees are marked as binary data (we have a lot of image
  assets).

> A possible solution would be to export the sqlite database as a list of 
> sql commands. This sql commands could be stored in a text file and be 
> put under version control. Before starting to work on the project I 
> could build from the text file the sqlite database. This approach means 
> some extra work but in principle it should work.

  That is the other common approach.  On the plus side, if the SQL is
  simple enough it will merge just like any other text file.  On the
  minus side, you have to deal with building and dumping the database
  files.

  For the "consumer" side of things, you can just treat the SQL dump as a
  "source file" and add a build rule to whatever environment you're in
  that re-creates the binary database file from the SQL source.  This,
  of course, assumes you have a "build environment" and not just a
  collection of documents.

  Things are a bit more complex for the "producer" side.  The most
  straight forward solution is to edit the SQL dump files and re-build
  the databases as part of the normal build process.  The dump files
  will then be handled by the revision system just like any other
  "source" file.

  Sometimes that's too complex, however.  If you need to edit the
  database file directly (or use a GUI or other tool to manage the
  database files) then you need a way to dump them back out.  Ideally
  this would be integrated into the editing tools, but that might not
  be a choice if you're using a third party tool.  Chances are good
  that if your schema is this complex the SQL dump isn't going to merge
  cleanly anyways-- you might as well just check the database file in
  directly.

  
  Which method is best depends a lot on how complex your data is, and
  how many people are likely to edit it at the same time.  In your
  specific situation, it sounds like multiple edits are unlikely.  In
  that case, I'd just add the database files to repository directly and
  be done with it.



   -j

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"'People who live in bamboo houses should not throw pandas.' Jesus said that."
   - "The Ninja", www.AskANinja.com, "Special Delivery 10: Pop!Tech 2006"
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] splite database under version control (subversion)?

[D. Richard Hipp]

On May 4, 2008, at 4:36 PM, M. Emal Alekozai wrote:
> Hi,
>> In the BIG db I have worked on there is a table that log every  
>> insert/update
>> on specific and important tables and a log of every sql statement  
>> execute
>> but I haven't ever see a db under version control with svn (or csv  
>> or git or
>> any other).
>>
> I'm (mis)using subversion more as a synchronization tool than as a
> version control system. I have a small software project and I have to
> work on this project on different computers (desktop, laptop, ...). To
> synchronize the project on all computers I use subversion. Before
> starting to work on one computer I make an "svn update" for the  
> project
> and after finishing I do a "svn commit".
...
>
> But the drawback is that the sqlite database is in a binary format and
> putting it into subversion is not optimal ;-).
>
> A possible solution would be to export the sqlite database as a list  
> of
> sql commands.
>
> Are there any other solutions /approaches for sqlite available?
>

http://www.fossil-scm.org/

I wrote fossil for a very specific use - a use which other DSCMs  
lacked necessary features.  But having written it, I am now finding  
that is is also very useful as a "synchronization tool", such as you  
describe above, and that is my primary use for fossil at the moment.   
I use multiple desktop and laptop systems to work on projects and I  
find that synchronizing using fossil is very convenient.

About six months ago, we shifted all of the documentation for SQLite  
out of CVS and into fossil.  The fossil repository for the SQLite  
documentation is working quite well.  See http://www.sqlite.org/docsrc/timeline 
  to see for yourself.  We might someday shift the SQLite core from  
CVS to fossil...

Fossil will work fine with binary files.  You won't be able to "diff"  
the files obviously, nor "merge" them if you fork your line of  
development.  But that is just the nature of binary files.  I don't  
think any SCM system is able to diff or merge arbitrary binary files.   
There may be modules for diffing and merging specific binary files  
formats (ex: DOC files) but not arbitrary binary files nor likely  
SQLite database files.  So take care not to fork.  But otherwise, you  
should be fine.

D. Richard Hipp
[EMAIL PROTECTED]



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] splite database under version control (subversion)?

[Federico Granata]

If you use svn only to sync over many pc maybe you can put your project on a
usb device (or usb hd) so you don't need to "sync" with svn.

If you WANT to use svn and you are under linux you can create an alias for
commit that make a dump of your db then commit it and one alias that update
and read the dump in db.

Maybe in windows you can make a batch, I don't know windows very well.

--
[image: Just A Little Bit Of
Geekness]
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza.
(Larry Wall).

On Sun, May 4, 2008 at 10:36 PM, M. Emal Alekozai <[EMAIL PROTECTED]> wrote:

> Hi,
> > In the BIG db I have worked on there is a table that log every
> insert/update
> > on specific and important tables and a log of every sql statement
> execute
> > but I haven't ever see a db under version control with svn (or csv or
> git or
> > any other).
> >
> I'm (mis)using subversion more as a synchronization tool than as a
> version control system. I have a small software project and I have to
> work on this project on different computers (desktop, laptop, ...). To
> synchronize the project on all computers I use subversion. Before
> starting to work on one computer I make an "svn update" for the project
> and after finishing I do a "svn commit". This approach works quite well
> for my case, because in general only text files (source code, latex
> documentation,...) change. The problem with this project is that I
> shifted all the "content" (labels, translation etc.) from the source
> code into a small sqlite database. This clean separation of "logic" and
> "content" makes the update and modification of the project much easier.
> But the drawback is that the sqlite database is in a binary format and
> putting it into subversion is not optimal ;-).
>
> A possible solution would be to export the sqlite database as a list of
> sql commands. This sql commands could be stored in a text file and be
> put under version control. Before starting to work on the project I
> could build from the text file the sqlite database. This approach means
> some extra work but in principle it should work.
>
> Are there any other solutions /approaches for sqlite available?
>
> Thanks
> Emal
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] splite database under version control (subversion)?

[M. Emal Alekozai]

Hi,
> In the BIG db I have worked on there is a table that log every insert/update
> on specific and important tables and a log of every sql statement execute
> but I haven't ever see a db under version control with svn (or csv or git or
> any other).
>   
I'm (mis)using subversion more as a synchronization tool than as a 
version control system. I have a small software project and I have to 
work on this project on different computers (desktop, laptop, ...). To 
synchronize the project on all computers I use subversion. Before 
starting to work on one computer I make an "svn update" for the project 
and after finishing I do a "svn commit". This approach works quite well 
for my case, because in general only text files (source code, latex 
documentation,...) change. The problem with this project is that I 
shifted all the "content" (labels, translation etc.) from the source 
code into a small sqlite database. This clean separation of "logic" and 
"content" makes the update and modification of the project much easier. 
But the drawback is that the sqlite database is in a binary format and 
putting it into subversion is not optimal ;-).

A possible solution would be to export the sqlite database as a list of 
sql commands. This sql commands could be stored in a text file and be 
put under version control. Before starting to work on the project I 
could build from the text file the sqlite database. This approach means 
some extra work but in principle it should work.

Are there any other solutions /approaches for sqlite available?

Thanks
Emal



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] splite database under version control (subversion)?

[Federico Granata]

In the BIG db I have worked on there is a table that log every insert/update
on specific and important tables and a log of every sql statement execute
but I haven't ever see a db under version control with svn (or csv or git or
any other).

--
[image: Just A Little Bit Of
Geekness]
Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza.
(Larry Wall).

On Wed, Apr 30, 2008 at 10:59 PM, <[EMAIL PROTECTED]> wrote:

> Dear Sqlite users,
>
> I want to put a sqlite database under version control (in my case
> subversion).
> As far as I know the sqlite database is a binary file.
> Always exporting and importing the database to a sql file is quite
> laborious .
> What is the standard approach for this ?
> Is there any "filter" available for subversion which does the conversion
> automatically?
>
> Thanks
> Emal
>
> --
> GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
> Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] splite database under version control (subversion)?

[memala]

Dear Sqlite users,

I want to put a sqlite database under version control (in my case subversion).
As far as I know the sqlite database is a binary file.
Always exporting and importing the database to a sql file is quite laborious .
What is the standard approach for this ?
Is there any "filter" available for subversion which does the conversion 
automatically?

Thanks
Emal

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users