Re: Adjust revision in new repository
On Fri, Sep 1, 2023 at 2:47 PM Magnus Lyrberg
wrote:
>
> On Fri, Sep 1, 2023 at 2:05 PM Yasuhito FUTATSUKI
> wrote:
> >
> > Although it makes a bunch of dummy empty commit, a dump file contains
> > empty revisions can increase youngest revision number keeping content
> > of the tree empty.
> >
> > e.g. A shell script to make a repositoy contains
> > 10 empty revisions:
> > [[[
> > #!/bin/sh
> >
> > repos_uuid='c68ffc52-e6c1-4053-9b3b-6e67a0e223f2'
> > rev0_date='2023-09-01T10:22:50.036256Z' # This should be just 27 letters.
> > number_of_commits=10
> >
> > produce_dump()
> > {
> > cat < > SVN-fs-dump-format-version: 2
> >
> > UUID: ${repos_uuid}
> >
> > Revision-number: 0
> > Prop-content-length: 56
> > Content-length: 56
> >
> > K 8
> > svn:date
> > V 27
> > ${rev0_date}
> > PROPS-END
> >
> > DUMP_HEAD_END
> >
> > rev=0
> > while [ $rev -lt $1 ]; do
> > rev=$(($rev+1))
> > cat < > Revision-number: $rev
> > Prop-content-length: 10
> > Content-length: 10
> >
> > PROPS-END
> >
> > REV_END
> > done
> > }
> >
> > svnadmin create new_repo
> > produce_dump "${number_of_commits}" | svnadmin load -q new_repo
> > svnadmin info new_repo
> > ]]]
>
> Thank you. This is very similar to our current solution. It would
> however be nice to avoid a lot of empty commits, hence my
> engagement in this list asking for alternative solutions.
>
> But perhaps there are none.
I'm not sure, but it sounds like that would be quite a hack, and I
don't think it will be possible.
The repository still has to give a sane reply if a user asks for "svn
update -r 2" or "svn ls https://server/svn@1";. If those revisions
really don't exist, what should the server answer? So I don't think
you can avoid creating those revisions, but you can leave them empty,
as suggested.
What is the problem in having those empty revisions anyway? I assume
they hardly take up any diskspace. If that's the only price you have
to pay for having this "old cruft removed but still original
rev-numbers repository", it sounds like a good deal to me (and it's
still a correctly working repository that behaves as designed).
--
Johan
RE: Problem storing passwords when using subversion
Where can I find the correct version of the docs for subversion 1.14.1 Mark From: Daniel Sahlberg Sent: Friday, September 1, 2023 5:54 AM To: Mark Wood-Patrick Cc: users@subversion.apache.org Subject: Re: Problem storing passwords when using subversion Importance: High External email: Use caution opening links or attachments Den fre 1 sep. 2023 kl 14:04 skrev Mark Wood-Patrick via users mailto:users@subversion.apache.org>>: I'm using subversion 1.14.1 on CentOS release 6.8 and trying to get subversion to store my credentials. Please check the svn --version command, it should say something like this towards the end of the output: [[[ The following authentication credential caches are available: * Plaintext cache in /home/dsg/.subversion * Gnome Keyring * GPG-Agent * KWallet (KDE) ]]] Viewing ~/.subversion/servers it seems like passwords should be stored by default. In ~/.subversion/config I have: password-stores = gpg-agent,gnome-keyring,kwallet However, when I try to do a checkout it continues to prompt me to enter my password, any idea what I'm doing wrong or how to determine why it's not working? Have you configured gnome keyring or kwallet? Are you using Subversion within a graphical session or through SSH? I think gnome keyring/kwallet are only available in graphical sessions. Where can I find the correct version of the docs for subversion 1.14.1 The default compile time configuration in Subversion 1.12 to 1.14 disables the plaintext cache (as you can see above, I have compiled my own version and enabled the plaintext cache). The FAQ explain this in more details. If you can accept the security implications of storing the password in plaintext there is a script available in the FAQ: https://subversion.apache.org/faq.html#plaintext-passwords Kind regards, Daniel Sahlberg
Re: Problem storing passwords when using subversion
Den fre 1 sep. 2023 kl 14:57 skrev Mark Wood-Patrick < mwoodpatr...@nvidia.com>: > Where can I find the correct version of the docs for subversion 1.14.1 > You get a long way with: $ svn help Otherwise the SVN book is still mostly accurate, there are only a few new features not yet described: https://svnbook.red-bean.com/nightly/en/index.html Kind regards, Daniel > > > Mark > > *From:* Daniel Sahlberg > *Sent:* Friday, September 1, 2023 5:54 AM > *To:* Mark Wood-Patrick > *Cc:* users@subversion.apache.org > *Subject:* Re: Problem storing passwords when using subversion > *Importance:* High > > > > *External email: Use caution opening links or attachments* > > > > Den fre 1 sep. 2023 kl 14:04 skrev Mark Wood-Patrick via users < > users@subversion.apache.org>: > > I'm using subversion 1.14.1 on CentOS release 6.8 and trying to get > subversion to store my credentials. > > > > Please check the svn --version command, it should say something like this > towards the end of the output: > > > > [[[ > > The following authentication credential caches are available: > > > > * Plaintext cache in /home/dsg/.subversion > > * Gnome Keyring > > * GPG-Agent > > * KWallet (KDE) > > ]]] > > > > > Viewing ~/.subversion/servers it seems like passwords should be stored by > default. > > In > > ~/.subversion/config > > I have: > > password-stores = gpg-agent,gnome-keyring,kwallet > > However, when I try to do a checkout it continues to prompt me to enter my > password, any idea what I'm doing wrong or how to determine why it's not > working? > > > > Have you configured gnome keyring or kwallet? > > > > Are you using Subversion within a graphical session or through SSH? I > think gnome keyring/kwallet are only available in graphical sessions. > > > > > Where can I find the correct version of the docs for subversion 1.14.1 > > > > The default compile time configuration in Subversion 1.12 to 1.14 disables > the plaintext cache (as you can see above, I have compiled my own version > and enabled the plaintext cache). > > > > The FAQ explain this in more details. > > > > If you can accept the security implications of storing the password in > plaintext there is a script available in the FAQ: > https://subversion.apache.org/faq.html#plaintext-passwords > > > > Kind regards, > > Daniel Sahlberg > > >
RE: Problem storing passwords when using subversion
Many thanks for the response much appreciated, after fixing an issue with gpg its working now Regards Mark From: Daniel Sahlberg Sent: Friday, September 1, 2023 5:54 AM To: Mark Wood-Patrick Cc: users@subversion.apache.org Subject: Re: Problem storing passwords when using subversion Importance: High External email: Use caution opening links or attachments Den fre 1 sep. 2023 kl 14:04 skrev Mark Wood-Patrick via users mailto:users@subversion.apache.org>>: I'm using subversion 1.14.1 on CentOS release 6.8 and trying to get subversion to store my credentials. Please check the svn --version command, it should say something like this towards the end of the output: [[[ The following authentication credential caches are available: * Plaintext cache in /home/dsg/.subversion * Gnome Keyring * GPG-Agent * KWallet (KDE) ]]] Viewing ~/.subversion/servers it seems like passwords should be stored by default. In ~/.subversion/config I have: password-stores = gpg-agent,gnome-keyring,kwallet However, when I try to do a checkout it continues to prompt me to enter my password, any idea what I'm doing wrong or how to determine why it's not working? Have you configured gnome keyring or kwallet? Are you using Subversion within a graphical session or through SSH? I think gnome keyring/kwallet are only available in graphical sessions. Where can I find the correct version of the docs for subversion 1.14.1 The default compile time configuration in Subversion 1.12 to 1.14 disables the plaintext cache (as you can see above, I have compiled my own version and enabled the plaintext cache). The FAQ explain this in more details. If you can accept the security implications of storing the password in plaintext there is a script available in the FAQ: https://subversion.apache.org/faq.html#plaintext-passwords Kind regards, Daniel Sahlberg
Re: Problem storing passwords when using subversion
Den fre 1 sep. 2023 kl 14:04 skrev Mark Wood-Patrick via users < users@subversion.apache.org>: > I'm using subversion 1.14.1 on CentOS release 6.8 and trying to get > subversion to store my credentials. > Please check the svn --version command, it should say something like this towards the end of the output: [[[ The following authentication credential caches are available: * Plaintext cache in /home/dsg/.subversion * Gnome Keyring * GPG-Agent * KWallet (KDE) ]]] > > Viewing ~/.subversion/servers it seems like passwords should be stored by > default. > > In > > ~/.subversion/config > > I have: > > password-stores = gpg-agent,gnome-keyring,kwallet > > However, when I try to do a checkout it continues to prompt me to enter my > password, any idea what I'm doing wrong or how to determine why it's not > working? > Have you configured gnome keyring or kwallet? Are you using Subversion within a graphical session or through SSH? I think gnome keyring/kwallet are only available in graphical sessions. > > Where can I find the correct version of the docs for subversion 1.14.1 > The default compile time configuration in Subversion 1.12 to 1.14 disables the plaintext cache (as you can see above, I have compiled my own version and enabled the plaintext cache). The FAQ explain this in more details. If you can accept the security implications of storing the password in plaintext there is a script available in the FAQ: https://subversion.apache.org/faq.html#plaintext-passwords Kind regards, Daniel Sahlberg
Re: Adjust revision in new repository
On Fri, Sep 1, 2023 at 2:05 PM Yasuhito FUTATSUKI
wrote:
>
> Although it makes a bunch of dummy empty commit, a dump file contains
> empty revisions can increase youngest revision number keeping content
> of the tree empty.
>
> e.g. A shell script to make a repositoy contains
> 10 empty revisions:
> [[[
> #!/bin/sh
>
> repos_uuid='c68ffc52-e6c1-4053-9b3b-6e67a0e223f2'
> rev0_date='2023-09-01T10:22:50.036256Z' # This should be just 27 letters.
> number_of_commits=10
>
> produce_dump()
> {
> cat < SVN-fs-dump-format-version: 2
>
> UUID: ${repos_uuid}
>
> Revision-number: 0
> Prop-content-length: 56
> Content-length: 56
>
> K 8
> svn:date
> V 27
> ${rev0_date}
> PROPS-END
>
> DUMP_HEAD_END
>
> rev=0
> while [ $rev -lt $1 ]; do
> rev=$(($rev+1))
> cat < Revision-number: $rev
> Prop-content-length: 10
> Content-length: 10
>
> PROPS-END
>
> REV_END
> done
> }
>
> svnadmin create new_repo
> produce_dump "${number_of_commits}" | svnadmin load -q new_repo
> svnadmin info new_repo
> ]]]
Thank you. This is very similar to our current solution. It would
however be nice to avoid a lot of empty commits, hence my
engagement in this list asking for alternative solutions.
But perhaps there are none.
Best regards
Magnus Lyrberg
Re: Adjust revision in new repository
On Fri, Sep 1, 2023 at 2:00 PM Johan Corveleyn wrote: > On Fri, Sep 1, 2023 at 11:05 AM Magnus Lyrberg > wrote: > > On Thu, Aug 31, 2023 at 4:51 PM Johan Corveleyn > wrote: > > > On Thu, Aug 31, 2023 at 2:21 PM Magnus Lyrberg > > > > Is there some other way besides making a bunch of dummy commits > > > > to reach our current revision number in a new repository? > > > > > > Maybe you can give svndumpfilter [1] a try to filter out the "cruft" > > > (after creating a dump file from the original repository). > > > Unfortunately 'svnadmin load' ignores the revision information in the > dump > > file. If the new repository is empty it will start with revision 1 > > regardless of > > what the dump file says. > > > > I made a quick test to verify this: > > > > svnadmin load /var/svn/repo2 < partial_dump.dump > > <<< Started new transaction, based on original revision 7 > > * adding path : test.txt ... done. > > > > --- Committed new rev 1 (loaded from original rev 7) >>> > > But what is partial_dump.dump? Can you show us the exact commands you > used to create it? > > Did you create this by dumping only revisions 7 and 8 from the > original repository, as in 'svnadmin dump /path/to/orig_repos -r7:8 > > partial_dump.dump'? In that case, it is expected to behave like you > described. > > Or did you create it by dumping the entire repository, and then > svndumpfilter-ing out the unneeded stuff, as in 'svnadmin dump > /path/to/orig_repos | svndumpfilter exclude /path/to/unneededstuff > > partial_dump.dump'? > > It is the last technique that I was suggesting, and I would expect > that to retain all the existing revision numbers (some revisions might > become empty revs because of the filtering, but they should still > "count"). > You are completely correct that the partial_dump.dump contained only revision 7 and 8, and that a filtered dump like you suggest will result in the correct revision number in the new repository. This does however also result in a number of empty revisions (dummy commits as I called them in the initial mail), which is what we want to avoid. What we would like to achieve is to have the current HEAD, without the history, in a new repository while still maintaining the revision number. Preferably without (quite a lot of) empty commits. Best regards Magnus Lyrberg
Re: Adjust revision in new repository
Hello,
On 2023/09/01 18:04, Magnus Lyrberg wrote:
Unfortunately 'svnadmin load' ignores the revision information in the dump
file. If the new repository is empty it will start with revision 1
regardless of
what the dump file says.
I made a quick test to verify this:
svnadmin load /var/svn/repo2 < partial_dump.dump
<<< Started new transaction, based on original revision 7
* adding path : test.txt ... done.
--- Committed new rev 1 (loaded from original rev 7) >>>
<<< Started new transaction, based on original revision 8
* editing path : test.txt ... done.
--- Committed new rev 2 (loaded from original rev 8) >>>
I want to achieve the new repository ending up at revision 8 (or even slightly
above 8), where my old repository was. But as not all revisions are in the
dump file it ended up on revision 2.
Although it makes a bunch of dummy empty commit, a dump file contains
empty revisions can increase youngest revision number keeping content
of the tree empty.
e.g. A shell script to make a repositoy contains
10 empty revisions:
[[[
#!/bin/sh
repos_uuid='c68ffc52-e6c1-4053-9b3b-6e67a0e223f2'
rev0_date='2023-09-01T10:22:50.036256Z' # This should be just 27 letters.
number_of_commits=10
produce_dump()
{
cat <
Problem storing passwords when using subversion
I'm using subversion 1.14.1 on CentOS release 6.8 and trying to get subversion to store my credentials. Viewing ~/.subversion/servers it seems like passwords should be stored by default. In ~/.subversion/config I have: password-stores = gpg-agent,gnome-keyring,kwallet However, when I try to do a checkout it continues to prompt me to enter my password, any idea what I'm doing wrong or how to determine why it's not working? Where can I find the correct version of the docs for subversion 1.14.1
Re: Adjust revision in new repository
On Fri, Sep 1, 2023 at 11:05 AM Magnus Lyrberg wrote: > On Thu, Aug 31, 2023 at 4:51 PM Johan Corveleyn wrote: > > On Thu, Aug 31, 2023 at 2:21 PM Magnus Lyrberg > > wrote: > > > > > > Hello. > > > > > > I'm not subscribed so please CC me in any response. > > > > > > Is there some other way besides making a bunch of dummy commits > > > to reach our current revision number in a new repository? > > > > Maybe you can give svndumpfilter [1] a try to filter out the "cruft" > > (after creating a dump file from the original repository). It has > > options like: > > > > --drop-empty-revs > > If the current filtering invocation causes any revision to be > > empty (i.e., the revision causes no change to the repository), removes > > these revisions from the final dump file. > > > > --renumber-revs > > Renumbers revisions that remain after filtering. > > > > which seems to indicate that by default (not using these options) it > > will keep the original revision numbering (even if you filter out > > entire revisions so they become empty). > > > > You'll have to create a dump file first, by using 'svnadmin dump' if > > you have file access to the repo, or 'svnrdump dump' if you only have > > remote access. Then svndumpfilter it, and 'svnadmin load' it into a > > new repository. Maybe first try it with a small test sample to see if > > it works as expected. > > Unfortunately 'svnadmin load' ignores the revision information in the dump > file. If the new repository is empty it will start with revision 1 > regardless of > what the dump file says. > > I made a quick test to verify this: > > svnadmin load /var/svn/repo2 < partial_dump.dump > <<< Started new transaction, based on original revision 7 > * adding path : test.txt ... done. > > --- Committed new rev 1 (loaded from original rev 7) >>> But what is partial_dump.dump? Can you show us the exact commands you used to create it? Did you create this by dumping only revisions 7 and 8 from the original repository, as in 'svnadmin dump /path/to/orig_repos -r7:8 > partial_dump.dump'? In that case, it is expected to behave like you described. Or did you create it by dumping the entire repository, and then svndumpfilter-ing out the unneeded stuff, as in 'svnadmin dump /path/to/orig_repos | svndumpfilter exclude /path/to/unneededstuff > partial_dump.dump'? It is the last technique that I was suggesting, and I would expect that to retain all the existing revision numbers (some revisions might become empty revs because of the filtering, but they should still "count"). -- Johan
Re: Adjust revision in new repository
On Thu, Aug 31, 2023 at 4:51 PM Johan Corveleyn wrote: > On Thu, Aug 31, 2023 at 2:21 PM Magnus Lyrberg > wrote: > > > > Hello. > > > > I'm not subscribed so please CC me in any response. > > > > Is there some other way besides making a bunch of dummy commits > > to reach our current revision number in a new repository? > > Maybe you can give svndumpfilter [1] a try to filter out the "cruft" > (after creating a dump file from the original repository). It has > options like: > > --drop-empty-revs > If the current filtering invocation causes any revision to be > empty (i.e., the revision causes no change to the repository), removes > these revisions from the final dump file. > > --renumber-revs > Renumbers revisions that remain after filtering. > > which seems to indicate that by default (not using these options) it > will keep the original revision numbering (even if you filter out > entire revisions so they become empty). > > You'll have to create a dump file first, by using 'svnadmin dump' if > you have file access to the repo, or 'svnrdump dump' if you only have > remote access. Then svndumpfilter it, and 'svnadmin load' it into a > new repository. Maybe first try it with a small test sample to see if > it works as expected. Unfortunately 'svnadmin load' ignores the revision information in the dump file. If the new repository is empty it will start with revision 1 regardless of what the dump file says. I made a quick test to verify this: svnadmin load /var/svn/repo2 < partial_dump.dump <<< Started new transaction, based on original revision 7 * adding path : test.txt ... done. --- Committed new rev 1 (loaded from original rev 7) >>> <<< Started new transaction, based on original revision 8 * editing path : test.txt ... done. --- Committed new rev 2 (loaded from original rev 8) >>> I want to achieve the new repository ending up at revision 8 (or even slightly above 8), where my old repository was. But as not all revisions are in the dump file it ended up on revision 2. Best regards Magnus Lyrberg
