You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Nguyen Vu Hung (VNC)" <vu...@vinicorp.com.vn> on 2011/02/22 10:42:47 UTC
Subverion 1.7 Centralized Metadata Storage
Hello all,
Could anyone please explain a little on the following feature?
Specifically, my questions are
* How it affects the current subversion (1.6) features and performance
* This way makes svn git-like :), my first impression is that:
subversion will be distributed, not centralized :)
Centralized Metadata Storage
A key feature of the changes introduced in Subversion 1.7 is the
centralization of worky copy metadata storage into a single location.
Instead of a .svn directory in every directory in the working copy,
Subversion 1.7 working copies have just one .svn directory—in the root
of the working copy. This directory includes (among other things) an
SQLite-backed database which contains all of the metadata Subversion
needs for that working copy.
Even though the data is stored in a structured format, the relationships
between the data are complex. We highly discourage external tools from
modifying the data held in this database, as such modification is likely
to result in working copy corruption.
Re: Subverion 1.7 Centralized Metadata Storage
Posted by Daniel Becroft <dj...@gmail.com>.
On Thu, Feb 24, 2011 at 12:16 PM, Nguyen Vu Hung (VNC) <
vuhung@vinicorp.com.vn> wrote:
> (2011/02/22 17:18), Ulrich Eckhardt wrote:
>
> On Tuesday 22 February 2011, Nguyen Vu Hung (VNC) wrote:
>
>
> * This way makes svn git-like :), my first impression is that:
> subversion will be distributed, not centralized :)
>
> SVN has one .svn directory in every (versioned) child directory of a working
> copy. This has the effect that every child directory of a working copy is
> itself a working copy. SVN 1.7 wants to centralise this, i.e. only use a
> single place to store this.
>
>
> This is a handy replacement for svn export function.
>
> Backward compatibility with 1.6 is another big concern who wants to
> upgrade from 1.6 or maintaining an ecosystem of both 1.6 and 1.7
>
How will this be any different from maintaining an ecosystem of 1.5 and 1.6?
Cheers,
Daniel B.
Re: Subverion 1.7 Centralized Metadata Storage
Posted by "Nguyen Vu Hung (VNC)" <vu...@vinicorp.com.vn>.
(2011/02/22 17:18), Ulrich Eckhardt wrote:
> On Tuesday 22 February 2011, Nguyen Vu Hung (VNC) wrote:
>
>> * This way makes svn git-like :), my first impression is that:
>> subversion will be distributed, not centralized :)
> SVN has one .svn directory in every (versioned) child directory of a working
> copy. This has the effect that every child directory of a working copy is
> itself a working copy. SVN 1.7 wants to centralise this, i.e. only use a
> single place to store this.
>
This is a handy replacement for svn export function.
Backward compatibility with 1.6 is another big concern who wants to
upgrade from 1.6 or maintaining an ecosystem of both 1.6 and 1.7
Re: Subverion 1.7 Centralized Metadata Storage
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Feb 22, 2011 at 04:55:48PM +0500, Waseem Bokhari wrote:
> If the structures are being changed then would there be any impact on
> existing Working copies or structure in SVN? I am working on Windows
> Environment ; please advice precautions and advices accordingly.
You can find advice in the release notes (which are still
work-in-progress because 1.7 hasn't been released yet):
http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng
RE: Subverion 1.7 Centralized Metadata Storage
Posted by Waseem Bokhari <wa...@netsoltech.com>.
If the structures are being changed then would there be any impact on
existing Working copies or structure in SVN? I am working on Windows
Environment ; please advice precautions and advices accordingly.
Regards
Waseem
-----Original Message-----
From: Stefan Sperling [mailto:stsp@elego.de]
Sent: Tuesday, February 22, 2011 4:44 PM
To: Thorsten Schöning
Cc: users@subversion.apache.org
Subject: Re: Subverion 1.7 Centralized Metadata Storage
On Tue, Feb 22, 2011 at 11:54:05AM +0100, Thorsten Schöning wrote:
> Guten Tag Ulrich Eckhardt,
> am Dienstag, 22. Februar 2011 um 11:18 schrieben Sie:
>
> > SVN has one .svn directory in every (versioned) child directory of a
working
> > copy. This has the effect that every child directory of a working copy
is
> > itself a working copy. SVN 1.7 wants to centralise this, i.e. only use a
> > single place to store this.
>
> This won't be configurable, won't it? I always found it really
> practical to be able to just copy/move entire sub folders of my
> working copy to a new location and have a functional working copy,
> without the need to checkout over and over again.
There will be a detach command to support this use case eventually.
So far it's not present in trunk so probably not in 1.7, but later.
In the meantime, you'll just have to live without this technically
unsupported use case which only worked because of a side-effect of
the 1.6 working copy design.
DISCLAIMER: This e-mail and any file transmitted with it are confidential and intended solely
for the use of the addressee. If you are not the intended recipient, you are hereby advised that
any dissemination, distribution or copy of this email or its attachments is strictly prohibited. If you
have received this email in error, please immediately notify us by return email and destroy this email
message and its attachments. This communication may contain forward-looking statements
relating to the development of NetSol Technologies' products and services and future operations.
The words "believe," "expect," "anticipate," "intend," variations of such words, and similar
expressions, identify forward looking statements, but their absence does not mean that the
statement is not forward-looking. Views and opinions contained herein are those of the author of
this email and do not necessarily represent those of NetSol Technologies. Statements contained
herein are not guarantees of future performance and are subject to certain risks, uncertainties and
assumptions that are difficult to predict. The company will not undertake to update any statements
contained herein.
WARNING: The recipient should check this email and any attachment for the presence of viruses.
Although the company has taken reasonable precautions to ensure no viruses are present in this
email, the company does not accept responsibility for any loss or damage arising from the use of
this email or attachment. Note: Please consider the environment before printing this e-mail.
Re: Subverion 1.7 Centralized Metadata Storage
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Feb 22, 2011 at 11:54:05AM +0100, Thorsten Schöning wrote:
> Guten Tag Ulrich Eckhardt,
> am Dienstag, 22. Februar 2011 um 11:18 schrieben Sie:
>
> > SVN has one .svn directory in every (versioned) child directory of a working
> > copy. This has the effect that every child directory of a working copy is
> > itself a working copy. SVN 1.7 wants to centralise this, i.e. only use a
> > single place to store this.
>
> This won't be configurable, won't it? I always found it really
> practical to be able to just copy/move entire sub folders of my
> working copy to a new location and have a functional working copy,
> without the need to checkout over and over again.
There will be a detach command to support this use case eventually.
So far it's not present in trunk so probably not in 1.7, but later.
In the meantime, you'll just have to live without this technically
unsupported use case which only worked because of a side-effect of
the 1.6 working copy design.
Re: Subverion 1.7 Centralized Metadata Storage
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Ulrich Eckhardt,
am Dienstag, 22. Februar 2011 um 11:18 schrieben Sie:
> SVN has one .svn directory in every (versioned) child directory of a working
> copy. This has the effect that every child directory of a working copy is
> itself a working copy. SVN 1.7 wants to centralise this, i.e. only use a
> single place to store this.
This won't be configurable, won't it? I always found it really
practical to be able to just copy/move entire sub folders of my
working copy to a new location and have a functional working copy,
without the need to checkout over and over again.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
Telefon: Potsdam: 0331-743881-0
E-Mail: tschoening@am-soft.de
Web: http://www.am-soft.de
AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow
Re: Subverion 1.7 Centralized Metadata Storage
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
On Tuesday 22 February 2011, Nguyen Vu Hung (VNC) wrote:
> Could anyone please explain a little on the following feature?
> Specifically, my questions are
>
> * How it affects the current subversion (1.6) features and performance
Not at all.
> * This way makes svn git-like :), my first impression is that:
> subversion will be distributed, not centralized :)
SVN has one .svn directory in every (versioned) child directory of a working
copy. This has the effect that every child directory of a working copy is
itself a working copy. SVN 1.7 wants to centralise this, i.e. only use a
single place to store this.
In any case, this has nothing to do with the way that "distributed" is used in
the context of version control systems. This is not about distributed vs
centralised repositories, but about WC metadata storage.
HTH
Uli
--
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at <http://www.dominolaser.com/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************