With a maintained server-side merkle tree for repos/users y'all would be a
little closer to the 'have set' fu of Perforce :)
Sent from my iPhone
> On Nov 1, 2016, at 6:29 AM, Julian Foad wrote:
>
> Branko Čibej wrote:
>> Paul Hammant wrote:
>>> I still think it would be good for sha1's to be c
Branko Čibej wrote:
> Paul Hammant wrote:
>> I still think it would be good for sha1's to be calculated for directories
>> *too*. Better still if those obeyed user permissions too.
>
> Server CPU is a limited resource. File content hashes are not affected
> by user permissions, so they can be comp
On 31.10.2016 13:31, Paul Hammant wrote:
> Thanks everyone - I was able to progress with this and pluck out SHA1s in a
> single operation.
>
> I still think it would be good for sha1's to be calculated for directories
> *too*. Better still if those obeyed user permissions too.
Server CPU is a li
Thanks everyone - I was able to progress with this and pluck out SHA1s in a
single operation.
I still think it would be good for sha1's to be calculated for directories
*too*. Better still if those obeyed user permissions too.
- Paul
Sent from my iPhone
> On Oct 12, 2016, at 9:05 AM, Ivan Zh
On 12 October 2016 at 14:03, Paul Hammant wrote:
> It's very exciting to hear that Subversion already calculates shas somewhere
> in the backend :)
I noted this multiple times on this thread: SHAs are optional at the
repository backend layer.
--
Ivan Zhakov
> -Original Message-
> From: Paul Hammant [mailto:p...@hammant.org]
> Sent: woensdag 12 oktober 2016 14:45
> To: Subversion Development
> Subject: Re: New SHA1 property for nodes returned 'svn ls --xml'
invocations.
>
> Svnsync looks to also leverage s
Svnsync looks to also leverage sha1s - I'll try to make a small experiment
later, and report back.
I see that svnadmin-dump will add in sha1 hashes. But that is server side only
:-(
> appropriate PROPFIND request. The ‘cadaver’ project build on top of the neon
> library might be an easy way to construct such a request.
>
> Bert
>
>
>
> From: Paul Hammant [mailto:p...@hammant.org]
> Sent: woensdag 12 oktober 2016 12:55
&
library might be an easy way to construct such a request.
Bert
From: Paul Hammant [mailto:p...@hammant.org]
Sent: woensdag 12 oktober 2016 12:55
To: Subversion Development
Subject: Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.
Yo
You're right - and in the fullness of time, I'll replace all the Svn uses
with their wire equivalents. If Shas were implemented at some future date,
I'd be happy for them to be available via PROPFIND. I's be even more happy
for them to be passed back to me in the response of a PUT.
Or are you say
tocol.
Bert
Sent from my Windows 10 phone
From: Paul Hammant
Sent: dinsdag 11 oktober 2016 14:09
To: Subversion Development
Subject: Re: New SHA1 property for nodes returned 'svn ls --xml' invocations.
Considering ..
svn info --xml
https://svn.apache.org/repos/asf/subversion/t
>
> > As a test, I'm using openssl to make huge files that
> > change wholly with every revision, and trying to find the top limits of
> > Subversion. Sadly I've only found the top limits of Docker on the mac so
> > far - 60GB.
>
> 60GB being the size of each revision of a single versioned file?
>
Paul Hammant wrote on Tue, Oct 11, 2016 at 20:14:02 -0400:
> > > I've read the ?kw=1 section of the release notes. My use case would not
> > > need keyword replacement. In fact it would need it to be off.
>
>
> > Are you sure? The only situations in which you'd need keywords
> > expansion *off*
>
> Thanks for these details, they clarify the picture.
>
:)
> > I've read the ?kw=1 section of the release notes. My use case would not
> > need keyword replacement. In fact it would need it to be off.
> Are you sure? The only situations in which you'd need keywords
> expansion *off* is if y
Paul Hammant wrote on Tue, Oct 11, 2016 at 08:09:06 -0400:
> kind="file">
> 3bc64b30547e9a0448feba6c6af48447dff2b980
⋮
> For the entry of directory that contains mod_dav_svn.c, I'd hope for the
> SHA1 to be a function of the SHA1s of the files within.
⋮
> For my use-case to work, I need to have
Personally and especially for my use case, I am not interested in the sha1 of
properties. Others might be though. Therefore two sha1 hashes - one without
props, and one with.
Sent from my iPhone
> On Oct 11, 2016, at 8:13 AM, Branko Čibej wrote:
>
>> On 11.10.2016 14:09, Paul Hammant wrote:
>
On 11.10.2016 14:09, Paul Hammant wrote:
> For the entry of directory that contains mod_dav_svn.c, I'd hope for the
> SHA1 to be a function of the SHA1s of the files within. That's Merkle-tree
> style - a super important feature generally as well as specifically to my
> use-case.
But are you only
Considering ..
svn info --xml
https://svn.apache.org/repos/asf/subversion/trunk/subversion/mod_dav_svn/mod_dav_svn.c
I would hope for a element at root level:
https://svn.apache.org/repos/asf/subversion/trunk/subversion/mod_dav_svn/mod_dav_svn.c
^/subversion/trunk/subversion/mod_dav_s
Paul Hammant wrote on Mon, Oct 10, 2016 at 22:23:25 -0400:
> In that page, there is a mention of 'ModMimeUsePathInfo' that can add
> properties transparently. One like it could optionally add a sha1 as a
> property and that be transient like svn:log, svn:date and svn:author.
>
Please don't worry
Not sure anyone is still reading this thread, but I'll reply because I'm
going to come back to it again someday.
Re http://svnbook.red-bean.com/en/1.8/svn.webdav.autoversioning.html (y'all
need to do the rel=canonical stuff to get the /1.8/ out of your google
search results).
In that page, there
On 2016-09-26 07:26:02 -0400, Paul Hammant wrote:
> Replying to various. I'm making a Dropbox-a-like client that uses
> Svn/WebDav/AutoIncrement as the server. Critical design goal - to *not*
> have a classic Svn working tree locally. Think 50GB of binary files sync'd
> down to a client, and a wi
On 2016-09-26 10:04:50 +0100, Julian Foad wrote:
> Daniel Shahaf wrote:
> > What would content hashes provide that comparing node-rev id's would not?
> 1. A node-rev id only exists for a tree that has been committed to
> the repository: there is no way to generate a node-rev id for an
> external tr
Merkle trees / hashes can help a server maintained graph of objects survive
"Bitrot"
(http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/
- data in SSD or HD being corrupted by (say) nutrinos over time. See also a
guy/gal lamenting their corr
> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: maandag 26 september 2016 09:09
> To: Julian Foad
> Cc: Paul Hammant ; Subversion Development
>
> Subject: Re: New SHA1 property for nodes returned 'svn ls --xml' invo
Replying to various. I'm making a Dropbox-a-like client that uses
Svn/WebDav/AutoIncrement as the server. Critical design goal - to *not*
have a classic Svn working tree locally. Think 50GB of binary files sync'd
down to a client, and a wish to not have that take 100GB of local storage.
> What w
Daniel Shahaf wrote:
Julian Foad wrote:
> Hi Paul. I'm +1 on the concept that implementing content hashes in
> Subversion would be useful. I think if we were designing Subversion today,
> the question would be "Why on earth wouldn't we design in a Merkle tree
> content hash?" as it is obviously (
Julian Foad wrote on Sun, Sep 25, 2016 at 22:30:54 +0100:
> Daniel Shahaf wrote:
> >Paul Hammant wrote:
> >>[...] It is easiest to
> >>hit up the root note and ask for a sha1, [...]
> >
> >Can you explain more about your use-case? [...]
>
> Hi Paul. I'm +1 on the concept that implementing conten
Daniel Shahaf wrote:
Paul Hammant wrote:
[...] It is easiest to
hit up the root note and ask for a sha1, [...]
Can you explain more about your use-case? [...]
Hi Paul. I'm +1 on the concept that implementing content hashes in
Subversion would be useful. I think if we were designing Subver
On Sat, Sep 24, 2016 at 08:34:05PM -0400, Paul Hammant wrote:
> Can I put the item in Jira and y'all mark it as a 2.0 feature.
Just filing a ticket in the issue tracker won't lead to any sort of progress.
You'll need to convince us why *we* want this feature and do the work,
or why we should spen
Paul Hammant wrote on Sat, Sep 24, 2016 at 08:36:37 -0400:
> More info: the technology I'm playing with doesn't do a svn checkout, but
> instead monitors the the repo via 'svn ls' (via polling). It is easiest to
> hit up the root note and ask for a sha1, then walk the tree (remotely) to
> get the a
I can pull down files from the Svn server (any version) and calc SHA1s on
the client side in only a few lines of Python. I'd keep a local database to
correlate Svn revision integers.
Can I put the item in Jira and y'all mark it as a 2.0 feature. As with
Merkle trees, you'd want it to extend from
On 24 September 2016 at 15:36, Paul Hammant wrote:
> In order to be able to do some Merkle-tree style functions on sets of files
> canonically held in Subversion, it would be great to ask Svn for a SHA1 for
> the files, or collections thereof from that node downwards.
>
> I would raise a new featu
Isn't 'ls --xml' a machine interface?
>
> Using the Subversion API directly would be the best way to do this. The
> checksum is available at the API level, but wouldn't serve any useful
> purpose in the output of 'svn ls' -- which is, after all, a user, not
> machine interface.
>
> -- Brane
>
On 24.09.2016 14:36, Paul Hammant wrote:
> In order to be able to do some Merkle-tree style functions on sets of files
> canonically held in Subversion, it would be great to ask Svn for a SHA1 for
> the files, or collections thereof from that node downwards.
>
> I would raise a new feature request
35 matches
Mail list logo
