Re: Tree conflict problem when merging two branches
On 13.08.2016 00:20, Ryan Schmidt wrote: >> On Aug 12, 2016, at 3:00 PM, André Roy wrote: >> >> Hi all, >> >> First time posting. >> >> -Create a repository (trunk/tags/branches), >> -Checkout /trunk, >> -Create branch1 in /branches/branch1, and checkout. >> -Create and checkout branch2. >> -Create file.txt in Trunk + add + commit. >> -Merge trunk changes into branch1 and commit. >> -Merge trunk changes into branch2 and commit. >> >> The problem: >> -Merge branch1 changes into branch2, gives me a Tree conflict with file.txt. >> >> Am I doing something wrong? > Probably :) > > Show us the exact transcript of commands you used for the above? > > Review the merging chapter in the book? > > http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html It appears to be a bug in our merge algorithm, it doesn't notice from mergeinfo that the file was already merged from the same source. See the attached reproduction script and transcripts for 1.9.x and trunk: the only difference is that the trunk merge resolver gives more options for resolving the conflict (thank you, stsp!) -- Brane repeat.sh Description: Bourne shell script $ ./repeat.sh + svnadmin create repo + svn mkdir -mtest file:///svntest/repo/trunk Committing transaction... Committed revision 1. + svn mkdir -mtest file:///svntest/repo/branches Committing transaction... Committed revision 2. + svn mkdir -mtest file:///svntest/repo/tags Committing transaction... Committed revision 3. + svn co file:///svntest/repo/trunk Checked out revision 3. + svn cp -mtest file:///svntest/repo/trunk file:///svntest/repo/branches/branch1 Committing transaction... Committed revision 4. + svn co file:///svntest/repo/branches/branch1 Checked out revision 4. + svn cp -mtest file:///svntest/repo/trunk file:///svntest/repo/branches/branch2 Committing transaction... Committed revision 5. + svn co file:///svntest/repo/branches/branch2 Checked out revision 5. + touch trunk/file.txt + svn add trunk/file.txt A trunk/file.txt + svn ci -mtest trunk Adding trunk/file.txt Transmitting file data .done Committing transaction... Committed revision 6. + cd branch1 + svn up Updating '.': At revision 6. + svn merge '^/trunk' . --- Merging r4 through r6 into '.': Afile.txt --- Recording mergeinfo for merge of r4 through r6 into '.': U . + svn ci -mtest Sending. Adding file.txt Committing transaction... Committed revision 7. + cd .. + cd branch2 + svn up Updating '.': At revision 7. + svn merge '^/trunk' . --- Merging r5 through r7 into '.': Afile.txt --- Recording mergeinfo for merge of r5 through r7 into '.': U . + svn ci -mtest Sending. Adding file.txt Committing transaction... Committed revision 8. + cd .. + cd branch2 + svn up Updating '.': At revision 8. + svn merge '^/branches/branch1' . --- Merging r4 through r8 into '.': C file.txt G . --- Recording mergeinfo for merge of r4 through r8 into '.': U . Summary of conflicts: Tree conflicts: 1 Tree conflict on 'file.txt' > local file obstruction, incoming file add upon merge Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: p Summary of conflicts: Tree conflicts: 1 + svn ci -mtest svn: E155015: Commit failed (details follow): svn: E155015: Aborting commit: '/svntest/branch2/file.txt' remains in conflict transcript-trunk.sh Description: Bourne shell script
Re: A couple thousand mp3 files (this is not spam I swear )
On 13.08.2016 02:56, Adam Jensen wrote:
> I sent this text (^above^) to users-subscr...@subversion.apache.org
> earlier today assuming that one need not be subscribed to post. This is
> a post-subscribe re-post.
>
> {https://subversion.apache.org/mailing-lists.html}::("you don't need to
> be subscribed to post")
Indeed you don't need to be subscribed to post, but the users-subscribe@
address doesn't post messages to the users@ list. :)
-- Brane
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/12/2016 08:56 PM, Adam Jensen wrote: > Here's the situation: I have ~1500 mp3 files (not pirated music), and > the collection is growing. The sizes range from ~100kB to ~300MB. The > content of these files will never change. The directory structure will > change, files will be moved, and new (additional) [mp3] files will be added. When a branch is created, are the files under revision control in the trunk copied to the branch (is there any duplication of files in the repository)?
Re: A couple thousand mp3 files (this is not spam I swear )
On 8/13/2016 11:07 AM, Adam Jensen wrote: On 08/12/2016 08:56 PM, Adam Jensen wrote: Here's the situation: I have ~1500 mp3 files (not pirated music), and the collection is growing. The sizes range from ~100kB to ~300MB. The content of these files will never change. The directory structure will change, files will be moved, and new (additional) [mp3] files will be added. When a branch is created, are the files under revision control in the trunk copied to the branch (is there any duplication of files in the repository)? No, the files are not copied; a rename is stored. These are "cheap copies", and this is an advantage over simple backups - if you want to save history using backups (per another suggestion), you need to retain one backup per significant event. That can add up. Subversion is most often used to store text files because it stores intra-file deltas when content is modified. Your use case is unusual, but as long as you don't make a lot of changes to the binary files, it will be efficient. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/13/2016 02:21 PM, David Chapman wrote: > On 8/13/2016 11:07 AM, Adam Jensen wrote: >> When a branch is created, are the files under revision control in the >> trunk copied to the branch (is there any duplication of files in the >> repository)? > > No, the files are not copied; a rename is stored. These are "cheap > copies", and this is an advantage over simple backups - if you want to > save history using backups (per another suggestion), you need to retain > one backup per significant event. That can add up. Thanks! That's a critical issue for my case where there is a large & growing core data-set and where it might be useful to have hundreds of branches, each representing a particular configuration of a subset, slice, or view of the core data-set. > Subversion is most often used to store text files because it stores > intra-file deltas when content is modified. Your use case is unusual, > but as long as you don't make a lot of changes to the binary files, it > will be efficient. Thanks [again] for the [vindicating] confirmation. I am inspired to set up a test case and explore this approach further :) Since, in my case, the binary files should/must never change, is there a way to configure a read-only attribute on specific files in the repository such that any subsequent attempt to check-in a change to any of those files will be rejected and an alert raised? The directory structures should remain changeable.
Re: A couple thousand mp3 files (this is not spam I swear )
On 8/13/2016 12:29 PM, Adam Jensen wrote: On 08/13/2016 02:21 PM, David Chapman wrote: On 8/13/2016 11:07 AM, Adam Jensen wrote: When a branch is created, are the files under revision control in the trunk copied to the branch (is there any duplication of files in the repository)? No, the files are not copied; a rename is stored. These are "cheap copies", and this is an advantage over simple backups - if you want to save history using backups (per another suggestion), you need to retain one backup per significant event. That can add up. Thanks! That's a critical issue for my case where there is a large & growing core data-set and where it might be useful to have hundreds of branches, each representing a particular configuration of a subset, slice, or view of the core data-set. Subversion is most often used to store text files because it stores intra-file deltas when content is modified. Your use case is unusual, but as long as you don't make a lot of changes to the binary files, it will be efficient. Thanks [again] for the [vindicating] confirmation. I am inspired to set up a test case and explore this approach further :) Since, in my case, the binary files should/must never change, is there a way to configure a read-only attribute on specific files in the repository such that any subsequent attempt to check-in a change to any of those files will be rejected and an alert raised? The directory structures should remain changeable. I don't know about an attribute, but you could define a hook script that would check the files being committed to ensure that no existing large binary files are being modified. I haven't done any work with hook scripts for several years, so I'll have to let someone else assist if you have more questions. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: A couple thousand mp3 files (this is not spam I swear )
On Sat, Aug 13, 2016 at 3:29 PM, Adam Jensen wrote: > On 08/13/2016 02:21 PM, David Chapman wrote: >> On 8/13/2016 11:07 AM, Adam Jensen wrote: >>> When a branch is created, are the files under revision control in the >>> trunk copied to the branch (is there any duplication of files in the >>> repository)? >> >> No, the files are not copied; a rename is stored. These are "cheap >> copies", and this is an advantage over simple backups - if you want to >> save history using backups (per another suggestion), you need to retain >> one backup per significant event. That can add up. > Thanks! That's a critical issue for my case where there is a large & > growing core data-set and where it might be useful to have hundreds of > branches, each representing a particular configuration of a subset, > slice, or view of the core data-set. Don't hurt yourself getting too clever. And don't forget that once ingested, Subversion is designed to *never let go* of content. Deleting any in the master simply won't ever clear the content from the core repository and its history, *ever*. Why do I bring this up? Because if it's MP3's and you discover a copyright violation, you cannot expunge the content without a *very* painful dump, iflter, and reload operation on a quite large repository. > Since, in my case, the binary files should/must never change, is there a > way to configure a read-only attribute on specific files in the > repository such that any subsequent attempt to check-in a change to any > of those files will be rejected and an alert raised? The directory > structures should remain changeable. That's what user privileges in "svnserve.conf" that would provide "write once" control are designed for. It would *not* prevent operations on the local file system by an administrator, using "file:///" based access. I assume that if an admin performs that kind of access, they mean what they're doing and are aware they're avoiding the filters. I also think you're being really optimistic about "my repository will only grow and never need to actually clear content". Accidental submission of copyright violating content would be my big worry. But I tend to pay more attention to that kind of concern than most.
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/13/2016 05:31 PM, Nico Kadel-Garcia wrote: > Don't hurt yourself getting too clever. And don't forget that once > ingested, Subversion is designed to *never let go* of content. > Deleting any in the master simply won't ever clear the content from > the core repository and its history, *ever*. > > Why do I bring this up? Because if it's MP3's and you discover a > copyright violation, you cannot expunge the content without a *very* > painful dump, iflter, and reload operation on a quite large > repository. The mp3 files, in this case, are indeed audio recordings but they represent an aspect of an expanding instrumentation system that is part of a specific [controlled ownership] environment. I don't think I have overlooked any relevant copyright issues related to the storage of the data. An indelible record is the goal (for now). >> Since, in my case, the binary files should/must never change, is there a >> way to configure a read-only attribute on specific files in the >> repository such that any subsequent attempt to check-in a change to any >> of those files will be rejected and an alert raised? The directory >> structures should remain changeable. > > That's what user privileges in "svnserve.conf" that would provide > "write once" control are designed for. It would *not* prevent > operations on the local file system by an administrator, using > "file:///" based access. I assume that if an admin performs that kind > of access, they mean what they're doing and are aware they're avoiding > the filters. What would an "svnserve.conf" file with "write once" access control look like? The book[1] shows something like this: -- [general] password-db = userfile realm = example realm # anonymous users aren't allowed anon-access = none # authenticated users can both read and write auth-access = write -- [1]: http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.auth.general I intend to host this repository from a FreeBSD-10.3(x86) system where `svnserve --version` is: -- svnserve, version 1.9.4 (r1740329) compiled Jul 28 2016, 02:56:08 on i386-portbld-freebsd10.1 Copyright (C) 2016 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository back-end (FS) modules are available: * fs_fs : Module for working with a plain file (FSFS) repository. * fs_x : Module for working with an experimental (FSX) repository. -- The manual page on that system `man svnserve.conf` describes: auth-access = none|read|write
A couple thousand mp3 files
Hi, I am considering a use of Subversion as a means to avoid accidentally deleting some important files that I will be working with on a regular basis. I am very interested to get comments on my plan or suggestions for alternative methods. Here's the situation: I have ~1500 mp3 files (not pirated music), and the collection is growing. The sizes range from ~100kB to ~300MB. The content of these files will never change. The directory structure will change, files will be moved, and new (additional) [mp3] files will be added. So basically, I am considering the use of Subversion as a live backup of sorts and a discipline/safety-net to prevent accidental deletion of any part of a continuously growing data-set while I explore different data organization and analysis strategies. My primary concerns are related to any potential file corruption, any data duplication, and/or any excessive network or disk I/O (other than the expected load of direct data communication). Again, any comments on [or analysis of] this plan, or suggestions for alternatives will be much appreciated!
Re: A couple thousand mp3 files (this is not spam I swear )
On 08/13/2016 08:09 AM, Branko Čibej wrote:
> On 13.08.2016 02:56, Adam Jensen wrote:
>> I sent this text (^above^) to users-subscr...@subversion.apache.org
>> earlier today assuming that one need not be subscribed to post. This is
>> a post-subscribe re-post.
>>
>> {https://subversion.apache.org/mailing-lists.html}::("you don't need to
>> be subscribed to post")
>
>
> Indeed you don't need to be subscribed to post, but the users-subscribe@
> address doesn't post messages to the users@ list. :)
I think the original message was in fact sent to users@ and the mention
(^above^) of users-subscribe@ was an independent copy and paste error.
The original post just showed up on:
http://mail-archives.apache.org/mod_mbox/subversion-users/201608.mbox/browser
Specifically:
http://mail-archives.apache.org/mod_mbox/subversion-users/201608.mbox/%3C57AE4DA6.9020106%40riseup.net%3E
Re: A couple thousand mp3 files (this is not spam I swear )
On 13.08.2016 20:21, David Chapman wrote: > On 8/13/2016 11:07 AM, Adam Jensen wrote: >> On 08/12/2016 08:56 PM, Adam Jensen wrote: >>> Here's the situation: I have ~1500 mp3 files (not pirated music), and >>> the collection is growing. The sizes range from ~100kB to ~300MB. The >>> content of these files will never change. The directory structure will >>> change, files will be moved, and new (additional) [mp3] files will >>> be added. >> When a branch is created, are the files under revision control in the >> trunk copied to the branch (is there any duplication of files in the >> repository)? >> >> > > No, the files are not copied; a rename is stored. These are "cheap > copies", and this is an advantage over simple backups - if you want to > save history using backups (per another suggestion), you need to > retain one backup per significant event. That can add up. > > Subversion is most often used to store text files because it stores > intra-file deltas when content is modified. Your use case is unusual, > but as long as you don't make a lot of changes to the binary files, it > will be efficient. Subversion uses binary deltas to store differences between files. It's essentially irrelevant if the files are text or something else, *unless* they're compressed (or encrypted) -- deltas between compressed versions of files with even minor differences are usually quite large, so in such cases Subversion may end up storing the complete file contents. (MP3 files are compressed audio, which is why I bring this up.) In any case, Subversion handles binary files just fine. The tree reorganizations you mention will cause minimal storage overhead. -- Brane
Re: A couple thousand mp3 files (this is not spam I swear )
On 14.08.2016 00:20, Adam Jensen wrote: > What would an "svnserve.conf" file with "write once" access control look like? There is (currently) no easy way to specify "write once" access for files in the repository; whoever can create a file can modify or delete it, too. You could achieve something like that by creating a custom pre-commit hook that would examine the pending commit transaction and reject the commit if it finds modifications or deletions of existing files But note that a rename is represented as an add+delete, so the hook would have to be rather smarter than it would seem at first glance to detect and allow renames without content modification. -- Brane
