You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by mark benedetto king <bk...@answerfriend.com> on 2002/12/15 15:12:02 UTC
[PATCH] Add repository UUIDs (fixes issue 1037)
This patch stores a UUID in the "svn:uuid" revprop on revision 0
Because the UUID should be immutable, an error is returned from
calls to svn_repos_fs_change_rev_prop for this property.
This enhancement was requested in issue 1037.
* subversion/include/svn_props.h
Add a new #define, SVN_PROP_REVISION_UUID.
* subversion/libsvn_repos/hooks.c
(svn_repos_fs_change_rev_prop): Return an error if the property
is SVN_PROP_REVISION_UUID.
* subversion/libsvn_repo/repos.c
#include apr_uuid.h for apr_uuid_*
(set_repos_uuid): new static function
(svn_repos_create): call set_repos_uuid
Index: subversion/include/svn_props.h
===================================================================
--- subversion/include/svn_props.h (revision 4130)
+++ subversion/include/svn_props.h (working copy)
@@ -200,6 +200,8 @@
/* The fs revision property that stores a commit's date. */
#define SVN_PROP_REVISION_DATE SVN_PROP_PREFIX "date"
+/* The fs revision property that stores a repository's unique id. */
+#define SVN_PROP_REVISION_UUID SVN_PROP_PREFIX "uuid"
Index: subversion/libsvn_repos/hooks.c
===================================================================
--- subversion/libsvn_repos/hooks.c (revision 4130)
+++ subversion/libsvn_repos/hooks.c (working copy)
@@ -314,6 +314,11 @@
{
svn_fs_t *fs = repos->fs;
+ if (! strcmp(name, SVN_PROP_REVISION_UUID))
+ return svn_error_create
+ (SVN_ERR_REPOS_DISABLED_FEATURE, 0, NULL,
+ "The repository UUID cannot be changed.\n");
+
/* Run pre-revprop-change hook */
SVN_ERR (run_pre_revprop_change_hook (repos, rev, author, name,
value, pool));
Index: subversion/libsvn_repos/repos.c
===================================================================
--- subversion/libsvn_repos/repos.c (revision 4130)
+++ subversion/libsvn_repos/repos.c (working copy)
@@ -17,6 +17,7 @@
#include <apr_pools.h>
#include <apr_file_io.h>
+#include <apr_uuid.h>
#include "svn_pools.h"
#include "svn_error.h"
@@ -679,6 +680,27 @@
}
+/* Generate a "universally unique id" (UUID) and associate
+ it with the SVN_PROP_REVISION_UUID property of revision 0
+ in REPOS, using POOL for all allocation */
+static svn_error_t *
+set_repos_uuid (svn_repos_t *repos, apr_pool_t *pool)
+{
+ apr_uuid_t uuid;
+ char buffer[APR_UUID_FORMATTED_LENGTH+1];
+ svn_string_t string;
+
+ apr_uuid_get (&uuid);
+ apr_uuid_format (buffer, &uuid);
+
+ string.len = APR_UUID_FORMATTED_LENGTH;
+ string.data = buffer;
+
+ return svn_fs_change_rev_prop (repos->fs, 0, SVN_PROP_REVISION_UUID,
+ &string, pool);
+}
+
+
svn_error_t *
svn_repos_create (svn_repos_t **repos_p, const char *path, apr_pool_t *pool)
{
@@ -770,6 +792,8 @@
(svn_path_join (path, SVN_REPOS__FORMAT, pool),
SVN_REPOS__VERSION, pool));
+ set_repos_uuid (repos, pool);
+
*repos_p = repos;
return SVN_NO_ERROR;
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add repository UUIDs (fixes issue 1037)
Posted by cm...@collab.net.
mark benedetto king <bk...@answerfriend.com> writes:
> On Sun, Dec 15, 2002 at 04:52:23PM +0000, Philip Martin wrote:
> > How is this going to work when a repository is dumped/loaded? Should
> > a dump/load change the UUID? Should the UUID be dumped? There would
> > appear to be cases where we want the loaded repository to have the
> > same UUID as the dumped repository, and other cases where they should
> > be distinct.
> >
>
> Sounds like we need one or more of the following:
>
> 1.) boolean option to dump for whether to include the UUID
> 2.) boolean option to load for whether to use the UUID
> 3.) "svnadmin reposid"
>
> (1) and/or (2) should be enough, but I have a feeling at least one user
> will accidentally overwrite their repository's UUID, thus invalidating
> all WCs. It might be nice to give them (3) to fix that sort of problem.
>
> What would you suggest?
I'd suggest that 'svnadmin dump' and 'svnadmin load' do nothing with
UUIDs, but admit to not having invested much thought into the matter.
The following is just my immediate reaction.
I'd like 'svnadmin create' to make a repository layout that generates
the UUID in a text file in the top directory (sibling of 'README' and
'format'). And if people want to dump and load a repository, they
should remember to copy over the UUID file when they also copy over
such things as the hook scripts.
Another similar suggestion would be to get our repository config-file
in place, which the UUID as one of the "[general]" options present in
that human-hackable text file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add repository UUIDs (fixes issue 1037)
Posted by Philip Martin <ph...@codematters.co.uk>.
mark benedetto king <bk...@answerfriend.com> writes:
> On Sun, Dec 15, 2002 at 04:52:23PM +0000, Philip Martin wrote:
> > How is this going to work when a repository is dumped/loaded? Should
> > a dump/load change the UUID? Should the UUID be dumped? There would
> > appear to be cases where we want the loaded repository to have the
> > same UUID as the dumped repository, and other cases where they should
> > be distinct.
> >
>
> Sounds like we need one or more of the following:
>
> 1.) boolean option to dump for whether to include the UUID
> 2.) boolean option to load for whether to use the UUID
> 3.) "svnadmin reposid"
>
> (1) and/or (2) should be enough, but I have a feeling at least one user
> will accidentally overwrite their repository's UUID, thus invalidating
> all WCs. It might be nice to give them (3) to fix that sort of problem.
>
> What would you suggest?
How about
- always include the UUID in the dump
- by default only load if the dump UUID and the repository UUID match
- provide --ignore-uuid to load even if the UUIDs don't match
- provide --update-uuid to load and update the repository UUID
Existing repositories don't have a UUID. Either the dump/load needs
to support dumps without a UUID, or we provide a command that creates
a UUID in an existing repository, and then insist that one is created
before dumping.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add repository UUIDs (fixes issue 1037)
Posted by cm...@collab.net.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
> > i'd say that we always dump the UUID when dumping revision zero of a
> > repository, and provide an svnadmin command to allow setting it. that
> > way we minimize the foot-shooting potential. people won't
> > accidentally screw up their working copies by accidentally changing
> > their repository's UUID, and for those (rare as far as i can see)
> > situations where one wants to change it you have the ability to.
>
> If the UUID is implemented as a revprop, then we must dump and load it
> like any other property. When the dump/load process starts
> special-casing certain kinds of repository data, we're doomed :-).
>
> If the administrator wants to tweak that revprop before or after the
> dump/load, that's her business.
Yeah, what he said.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add repository UUIDs (fixes issue 1037)
Posted by Justin Erenkrantz <je...@apache.org>.
--On Monday, December 16, 2002 4:49 AM +0100
"=?UTF-8?B?QnJhbmtvIMSMaWJlag==?=" <br...@xbc.nu> wrote:
> This whole discussion merely confirms my suspicion that we've put
> way too little thought into a) what repository UUIDs are good for,
> and b) how to implement them.
>
> Givent that, -1 on this change until we have a clear design,
> including documenting and solving these corner-case side effects,
> outlining an upgrade path, etc. ad nauseam. If that means we don't
> get UUIDs in the repository for another month or two or six, so be
> it.
Agreed. There may be reasons for having a repository UUID, but I
don't think that's been clarified to my satisfaction, either. You
don't really need a unique identifier for lots of
replication/distributed repository schemes.
Adding it when we have no idea how it will actually be used may just
make it harder when we've actually thought about it. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add repository UUIDs (fixes issue 1037)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> >So if we can figure out a good way to handle this case, and satisfy
> >ourselves that there isn't another nasty question lurking, then we can
> >implement them before 1.0.
>
> Heh. That's excactly what I said. :-)
Yeah, but you know, I never really understand anything anyone says
until I've rephrased it back at them, and taken credit to boot.
:-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add repository UUIDs (fixes issue 1037)
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>So if we can figure out a good way to handle this case, and satisfy
>ourselves that there isn't another nasty question lurking, then we can
>implement them before 1.0.
>
Heh. That's excactly what I said. :-)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add repository UUIDs (fixes issue 1037)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> This whole discussion merely confirms my suspicion that we've put way
> too little thought into a) what repository UUIDs are good for, and b)
> how to implement them.
>
> Givent that, -1 on this change until we have a clear design, including
> documenting and solving these corner-case side effects, outlining an
> upgrade path, etc. ad nauseam. If that means we don't get UUIDs in the
> repository for another month or two or six, so be it.
>
> As I said elsewhere, we can't continue with this hack-and-test approach
> to core repository/filesystem features. If we want to see a 1.0 in the
> next three months, we have to stabilize things now. I'd be much happier
> without repository UUIDs in 1.0 that with a design/implementation that
> doesn't address even the first-order side effects satisfactorily.
+1 on Brane's -1, for the reasons he gives above :-).
However, I think the dump/load question might be the only corner case
associated with having a UUID in the repository (there will be many
more corner cases when we start *using* them, of course, but we're not
implementing that part yet).
So if we can figure out a good way to handle this case, and satisfy
ourselves that there isn't another nasty question lurking, then we can
implement them before 1.0. But we clearly need to think more about
them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add repository UUIDs (fixes issue 1037)
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>Garrett Rooney <ro...@electricjellyfish.net> writes:
>
>
>>i'd say that we always dump the UUID when dumping revision zero of a
>>repository, and provide an svnadmin command to allow setting it. that
>>way we minimize the foot-shooting potential. people won't
>>accidentally screw up their working copies by accidentally changing
>>their repository's UUID, and for those (rare as far as i can see)
>>situations where one wants to change it you have the ability to.
>>
>>
>
>If the UUID is implemented as a revprop, then we must dump and load it
>like any other property. When the dump/load process starts
>special-casing certain kinds of repository data, we're doomed :-).
>
>If the administrator wants to tweak that revprop before or after the
>dump/load, that's her business.
>
>
>
This whole discussion merely confirms my suspicion that we've put way
too little thought into a) what repository UUIDs are good for, and b)
how to implement them.
Givent that, -1 on this change until we have a clear design, including
documenting and solving these corner-case side effects, outlining an
upgrade path, etc. ad nauseam. If that means we don't get UUIDs in the
repository for another month or two or six, so be it.
As I said elsewhere, we can't continue with this hack-and-test approach
to core repository/filesystem features. If we want to see a 1.0 in the
next three months, we have to stabilize things now. I'd be much happier
without repository UUIDs in 1.0 that with a design/implementation that
doesn't address even the first-order side effects satisfactorily.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add repository UUIDs (fixes issue 1037)
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> i'd say that we always dump the UUID when dumping revision zero of a
> repository, and provide an svnadmin command to allow setting it. that
> way we minimize the foot-shooting potential. people won't
> accidentally screw up their working copies by accidentally changing
> their repository's UUID, and for those (rare as far as i can see)
> situations where one wants to change it you have the ability to.
If the UUID is implemented as a revprop, then we must dump and load it
like any other property. When the dump/load process starts
special-casing certain kinds of repository data, we're doomed :-).
If the administrator wants to tweak that revprop before or after the
dump/load, that's her business.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add repository UUIDs (fixes issue 1037)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Sunday, December 15, 2002, at 05:24 PM, mark benedetto king wrote:
>
> Sounds like we need one or more of the following:
>
> 1.) boolean option to dump for whether to include the UUID
> 2.) boolean option to load for whether to use the UUID
> 3.) "svnadmin reposid"
>
> (1) and/or (2) should be enough, but I have a feeling at least one user
> will accidentally overwrite their repository's UUID, thus invalidating
> all WCs. It might be nice to give them (3) to fix that sort of
> problem.
>
> What would you suggest?
i'd say that we always dump the UUID when dumping revision zero of a
repository, and provide an svnadmin command to allow setting it. that
way we minimize the foot-shooting potential. people won't accidentally
screw up their working copies by accidentally changing their
repository's UUID, and for those (rare as far as i can see) situations
where one wants to change it you have the ability to.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add repository UUIDs (fixes issue 1037)
Posted by mark benedetto king <bk...@answerfriend.com>.
On Sun, Dec 15, 2002 at 04:52:23PM +0000, Philip Martin wrote:
> How is this going to work when a repository is dumped/loaded? Should
> a dump/load change the UUID? Should the UUID be dumped? There would
> appear to be cases where we want the loaded repository to have the
> same UUID as the dumped repository, and other cases where they should
> be distinct.
>
Sounds like we need one or more of the following:
1.) boolean option to dump for whether to include the UUID
2.) boolean option to load for whether to use the UUID
3.) "svnadmin reposid"
(1) and/or (2) should be enough, but I have a feeling at least one user
will accidentally overwrite their repository's UUID, thus invalidating
all WCs. It might be nice to give them (3) to fix that sort of problem.
What would you suggest?
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Add repository UUIDs (fixes issue 1037)
Posted by Philip Martin <ph...@codematters.co.uk>.
mark benedetto king <bk...@answerfriend.com> writes:
> This patch stores a UUID in the "svn:uuid" revprop on revision 0
> Because the UUID should be immutable, an error is returned from
> calls to svn_repos_fs_change_rev_prop for this property.
>
> This enhancement was requested in issue 1037.
>
> * subversion/include/svn_props.h
> Add a new #define, SVN_PROP_REVISION_UUID.
>
> * subversion/libsvn_repos/hooks.c
> (svn_repos_fs_change_rev_prop): Return an error if the property
> is SVN_PROP_REVISION_UUID.
>
> * subversion/libsvn_repo/repos.c
> #include apr_uuid.h for apr_uuid_*
> (set_repos_uuid): new static function
> (svn_repos_create): call set_repos_uuid
How is this going to work when a repository is dumped/loaded? Should
a dump/load change the UUID? Should the UUID be dumped? There would
appear to be cases where we want the loaded repository to have the
same UUID as the dumped repository, and other cases where they should
be distinct.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org