Re: value in 'svnadmin verify' cron job? (or is 'svnadmin hotcopy' enough?)
s...@trodman.com wrote on Wed, Sep 08, 2010 at 19:12:01 -0500: > Assuming a nightly 'svnadmin hotcopy' is run w/o errors, is > there value in periodically running one or both of?: > > svnadmin verify REPO-PATHNAME 2>&1 |egrep -v '^\* Verified revision > [0-9]+\.' > > svnadmin dump -q --deltas REPO-PATHNAME >/dev/null > YES. > Goal of grep and redirects is to only display errors or warnings. > > -- > Does a successful 'svnadmin hotcopy' indicate a clean bill of > health for the repository, or might 'svnadmin verify' still > locate problems? > The latter. > Would like to detect corruption in repository as soon as possible. > +1 > -- > thanks > Tom
Re: Detecting CR eol
On Wednesday 08 Sep 2010, Ryan Schmidt wrote: > On Sep 8, 2010, at 10:27, Campbell Allan wrote: > > Before sending my previous reply I had tested it with a file changed > > using unix2dos. Prior to the commit svn diff only shows the text changes > > ignoring the line endings. I haven't explicitly tested changing a single > > line ending within the file but have done a quick concatenation test with > > half the file with LF and the other half CRLF. When committed the entire > > file in the working copy is changed to LF. > > As I recall, if a file with svn:eol-style set has inconsistent line endings > (e.g. some LF, some CRLF), Subversion will reject the commit and require > the user to make the file's line endings consistent before proceeding. > Though I don't know whether this is happening on the client or on the > server. > Originally I thought the same which is why I tested it but subversion only complains if the svn:eol-style is not set. If the property is set then the official client (1.6.12 with 1.6.11 server. I've not tested others) converts the files in the working copy on commit. Diffs show only the text changes ignoring the line endings. The only question I can't answer is if the server would reject the commit if the client does not do the conversion. This would almost seem like a bug though unless the svn:eol-style property is only meant as a hint to the client in which case the documentation should be updated. I've got a test script for repeating this quickly that I can post. I did notice there appears to be an inconsistency but I don't believe this is a bug in subversion as unix2dos also exibits the same problem. The test script concatenates three smaller files together to create a larger file. When subversion or unix2dos converts this file to have CRLF endings the resulting file only contains the first of the three smaller files. > > The part of the book that I felt was relevant is when the line ending is > > set to native subversion will store the file in the repository with LF's > > only. The client is then changing this to reflect the preferences of the > > client OS. > > My understanding is that if svn:eol-style is set to *any value* then the > repository stores the file with LF line endings and the client does eol > translation to your desired style. -- __ Sword Ciboodle is the trading name of ciboodle Limited (a company registered in Scotland with registered number SC143434 and whose registered office is at India of Inchinnan, Renfrewshire, UK, PA4 9LH) which is part of the Sword Group of companies. This email (and any attachments) is intended for the named recipient(s) and is private and confidential. If it is not for you, please inform us and then delete it. If you are not the intended recipient(s), the use, disclosure, copying or distribution of any information contained within this email is prohibited. Messages to and from us may be monitored. If the content is not about the business of the Sword Group then the message is neither from nor sanctioned by us. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this email or any attachment. __
Extracting files without keyword expansion
Is there any way possible (aside from write a script to generate modified files) to update, checkout or otherwise fetch files from svn *without* having it honour the svn:keywords property (and without permanently removing said property)? This is for the purposes of doing some out-of-repo difference checking. I have one set of files with unexpanded headers (as if they were about to freshly be added), and another from a repo. with expanded headers, and of course they all show up as different. -- [n...@fnx ~]# rm -f .signature [n...@fnx ~]# ls -l .signature ls: .signature: No such file or directory [n...@fnx ~]# exit
Re: Detecting CR eol
On Wednesday 08 Sep 2010, Csaba Raduly wrote:
> Hi Giulio,
>
> On Wed, Sep 8, 2010 at 10:25 AM, Giulio Troccoli wrote:
> > I am writing a pre-commit hook script in perl. One of the requirement is
> > that all files (luckily they are all text files) have the svn:eol-style
> > property set to LF and the actual eol is indeed LF. If that's not the
> > case I will reject the commit and direct the user to a page on our
> > intranet to explain what to do to fix it.
> >
> > My problem is how to detect whether the eol is LF and nothing else. I'm
> > developing on Linux (Centos 5) and Perl 5.10. Subversion is 1.6.9, if it
> > matters.
> >
> > I thought about using the dos2unix utility (we only use Windows or Linux)
> > and then check that the file hasn't changed, but it seems a lot of
> > processing.
> >
> > My second idea was to use a regular expression to check each line of each
> > file. This way at least I would stop as soon as I find an eol that is not
> > LF, saving some processing. I still need to svn cat each file into an
> > array I think.
>
> You need to use svnlook cat, but there is no need to read all its
> output into memory. You can process it line-by-line.
> Here's an outline (completely untested)
>
I had written something similar for someone else on here for checking
properties being set but I like this approach better. Only comment to make
though is this assumes only updates are occurring. It will fail on any adds,
removals or property changes as the filename will not be stripped properly.
My perl is too rusty to be able to do it so succintly as this though.
> #!/usr/bin/perl -w
> use strict;
>
> my ($REPOS, $TXN) = @ARGV;
>
> my $crlf = 0;
>
> ... determine the list of files
> my @files = `svnlook changed -t $TXN $REPOS`;
perhaps this to filter out removed files?
my @files = `svnlook changed -t $TXN $REPOS | grep -E '^[AU]'`;
> chomp @files; # remove the newline at the end
> s/^U\s+// for @files; # remove the leading U
I do know this bit should be changed for including added files.
s/^[AU]\s+// for @files; # remove the leading A or U
>
> FILE:
> foreach my $file (@files) {
> open (SVN, "svnlook cat $file |") or die "open pipe failed: $!"
> while () # read from the pipe, one line at a time
> {
> chomp; # cut the platform-specific line end. On Unix, this drops
> the \n but keeps the \r
> if ( /^M$/ ) { # last character is a \r (a.k.a. Control-M)
> $crlf = 1; last FILE;
> }
> }
> close(SVN) or die "close pipe failed: $!" # it is very important to
> check the close on pipes
> }
>
> if ($crlf)
> {
> die "$file contains DOS line endings";
> }
--
__
Sword Ciboodle is the trading name of ciboodle Limited (a company
registered in Scotland with registered number SC143434 and whose
registered office is at India of Inchinnan, Renfrewshire, UK,
PA4 9LH) which is part of the Sword Group of companies.
This email (and any attachments) is intended for the named
recipient(s) and is private and confidential. If it is not for you,
please inform us and then delete it. If you are not the intended
recipient(s), the use, disclosure, copying or distribution of any
information contained within this email is prohibited. Messages to
and from us may be monitored. If the content is not about the
business of the Sword Group then the message is neither from nor
sanctioned by us.
Internet communications are not secure. You should scan this
message and any attachments for viruses. Under no circumstances
do we accept liability for any loss or damage which may result from
your receipt of this email or any attachment.
__
Re: svnsync failure when syncing with a repository that used ISO-8859-1 for log messages
CC += dev@, and let me point you to our patch submission guidelines:
http://subversion.apache.org/docs/community-guide/general.html#patches
Summary for dev@: allow svnsync to translate non-UTF-8 log messages to UTF-8.
(more below)
Daniel Trebbien wrote on Wed, Sep 08, 2010 at 18:58:06 -0700:
> On Wed, Sep 8, 2010 at 4:39 PM, Daniel Trebbien wrote:
> > I think that a call to `svn_subst_translate_string`
> > (http://svn.collab.net/svn-doxygen/svn__subst_8h.html#a29) needs to be
> > added in the `svnsync_normalize_revprops` function when `propname` is
> > "svn:log".
>
> After applying the following patch to `subversion/svnsync/sync.c`, I
> can confirm that the "svnsync: Error while replaying commit" error
> disappears, allowing the sync to complete, and that the problem is
> indeed a log message encoding issue:
> diff --git a/subversion/svnsync/sync.c b/subversion/svnsync/sync.c
> index 8f7be9e..c7a5e38 100644
> --- a/subversion/svnsync/sync.c
> +++ b/subversion/svnsync/sync.c
> @@ -114,6 +114,14 @@ svnsync_normalize_revprops(apr_hash_t *rev_props,
>/* And count this. */
>(*normalized_count)++;
> }
> +
> + if (strcmp(propname, "svn:log") == 0)
> +{
Should this use svn_prop_needs_translation()?
> + svn_string_t *new_propval;
> + SVN_ERR(svn_subst_translate_string(&new_propval, propval,
> "ISO-8859-1", pool));
> + apr_hash_set(rev_props, propname, APR_HASH_KEY_STRING, propval
> = new_propval);
Please, please, please, no assignment inside a function call.
^
> + (*normalized_count)++;
> +}
> }
> }
>return SVN_NO_ERROR;
>
>
> Here I hard-coded the encoding, but I think that the encoding to use
> should be retrieved from the Subversion config file. Now the questions
> are:
>
> 1. What is the best way to pass the `log-encoding` option of the
> [miscellany] section to the `svnsync_normalize_revprops` function?
>
What is 'log-encoding' normally used for? Only for recoding the commit
message supplied by an editor, right? So I'm not sure we should use it
here, perhaps a new command-line option will be better. (svnsync
$subcommand --source-encoding=%s)
If you'd like to use a config option, get it from 'svn_config_t *config'
in main(), stash it in the subcommand baton, and drill it down as deep
as needed.
And either way, the default behaviour should be to translate nothing.
(If you always translate from latin1, you break syncs for people who,
correctly, used UTF-8 log messages the entire time.)
> 2. Should `svnsync` always store the log messages in UTF-8 even though
> the original repository log message encoding is different?
>
You have no choice on the matter: the RA API instructs you to supply it
a UTF-8 log message. (IIRC, even the libsvn_client API expects an
already-UTF-8 message.)
> 3. Should there be separate configuration options for the log message
> encoding of the source repository and the log message encoding of the
> destination repository?
No, see (2).
Re: svnsync failure when syncing with a repository that used ISO-8859-1 for log messages
Daniel Trebbien wrote on Wed, Sep 08, 2010 at 18:58:06 -0700: > On Wed, Sep 8, 2010 at 4:39 PM, Daniel Trebbien wrote: > > I think that a call to `svn_subst_translate_string` > > (http://svn.collab.net/svn-doxygen/svn__subst_8h.html#a29) Where did you find a link to this doxygen instance? Our doxygen has moved to here: http://subversion.apache.org/docs/#api So I'd like to update links.
Re: Using PAM to authenticate user?
On Thursday 09 Sep 2010, Alexander Skwar wrote: > There are modules for apache out there, which allow PAM auth. Mod-auth- > external seems to be easy to use (haven't tried it myself, though). > > http://code.google.com/p/mod-auth-external/ > > Alexander > > Am 09.09.2010 um 08:42 schrieb "Curley, John" > > : > >> -Original Message- > >> From: Curley, John [mailto:john.cur...@windriver.com] > >> Sent: Wednesday, September 08, 2010 11:33 PM > >> To: users@subversion.apache.org > >> Subject: Using PAM to authenticate user? > >> > >> Has anyone use Pluggable Authentication Module (PAM) for user > > > > authentication, within Subversion? > > > >> If that is currently not supported, is it possibly future option? > >> > >> Thank you, > >> --John > >> > >> > >> "Living on Earth may be expensive, but it includes an annual free > >> trip > > > > around the Sun." > > > >> ~author unknown > > > > I forgot to add, like RSA? Assuming you are meaning when connecting through apache then I've also used mod_auth_pam 2.0-1.1.1 and it works really well, once it is patched. I don't believe it is being actively developed at the moment though. The patch improves performance by doing some caching and also allows the application name to be configured as the original sources had hard coded it to 'apache'. I can send along the details and patch if you wish. -- __ Sword Ciboodle is the trading name of ciboodle Limited (a company registered in Scotland with registered number SC143434 and whose registered office is at India of Inchinnan, Renfrewshire, UK, PA4 9LH) which is part of the Sword Group of companies. This email (and any attachments) is intended for the named recipient(s) and is private and confidential. If it is not for you, please inform us and then delete it. If you are not the intended recipient(s), the use, disclosure, copying or distribution of any information contained within this email is prohibited. Messages to and from us may be monitored. If the content is not about the business of the Sword Group then the message is neither from nor sanctioned by us. Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this email or any attachment. __
Re: Extracting files without keyword expansion
svn export --ignore-keywords (exists in trunk; don't know if it's in 1.6) Neil Bird wrote on Thu, Sep 09, 2010 at 11:41:25 +0100: > > Is there any way possible (aside from write a script to generate > modified files) to update, checkout or otherwise fetch files from svn > *without* having it honour the svn:keywords property (and without > permanently removing said property)? > > This is for the purposes of doing some out-of-repo difference checking. > I have one set of files with unexpanded headers (as if they were about to > freshly be added), and another from a repo. with expanded headers, and of > course they all show up as different. > > -- > [n...@fnx ~]# rm -f .signature > [n...@fnx ~]# ls -l .signature > ls: .signature: No such file or directory > [n...@fnx ~]# exit
Re: Extracting files without keyword expansion
On Thu, Sep 09, 2010 at 11:41:25AM +0100, Neil Bird wrote: > > Is there any way possible (aside from write a script to generate > modified files) to update, checkout or otherwise fetch files from > svn *without* having it honour the svn:keywords property (and > without permanently removing said property)? > > This is for the purposes of doing some out-of-repo difference > checking. I have one set of files with unexpanded headers (as if > they were about to freshly be added), and another from a repo. with > expanded headers, and of course they all show up as different. To support this exact use case, I've added an --ignore-keywords option to svn export some time ago: http://svn.apache.org/viewvc?view=revision&revision=892471 This will be released in 1.7. Before then, there's no way to do this with stock svn. You'll have to unexpand keywords from the exported data manually. In the mean time, if you're comfortable with patching your Subversion 1.6.x build, try the patch below which should unconditionally disable keyword expansion upon export. No warranty though :) Stefan Index: subversion/libsvn_client/export.c === --- subversion/libsvn_client/export.c (revision 992007) +++ subversion/libsvn_client/export.c (working copy) @@ -700,8 +700,10 @@ change_file_prop(void *file_baton, if (strcmp(name, SVN_PROP_EOL_STYLE) == 0) fb->eol_style_val = svn_string_dup(value, fb->pool); +#if 0 else if (strcmp(name, SVN_PROP_KEYWORDS) == 0) fb->keywords_val = svn_string_dup(value, fb->pool); +#endif else if (strcmp(name, SVN_PROP_EXECUTABLE) == 0) fb->executable_val = svn_string_dup(value, fb->pool);
Re: Extracting files without keyword expansion
On Thu, Sep 9, 2010 at 6:41 AM, Neil Bird wrote: > > Is there any way possible (aside from write a script to generate modified > files) to update, checkout or otherwise fetch files from svn *without* > having it honour the svn:keywords property (and without permanently removing > said property)? > > This is for the purposes of doing some out-of-repo difference checking. I > have one set of files with unexpanded headers (as if they were about to > freshly be added), and another from a repo. with expanded headers, and of > course they all show up as different. Our upstream developers added the "--ignore-keywords" option in the trunk. But you can also look into using "diff" tools that can be set to ignore selected keywords, such as "--ignore-matching-lines" for GNU diff. If it's going to be an ongoing issue, you might also consider disabling keyword expansion entirely, even blocking its use in your pre-commit scripts. Some source control systems do not support them at all, believing that the source control system should not *touch* the actual contents of the file. (git, for example, does not support keywords.) It does have its uses for version tracking in exported files, but it can be an issue as well as you are seeing.
Re: Detecting CR eol
On Wed, Sep 8, 2010 at 11:27 AM, Campbell Allan wrote: > The part of the book that I felt was relevant is when the line ending is set > to native subversion will store the file in the repository with LF's only. > The client is then changing this to reflect the preferences of the client OS. Yeah, this can be nasty to stuff in a pre-commit hook. The use of the "native" EOL setting is almost always a mistake, especially with CIFS or NFS shared working directories. These cross-platform working copies are actually quite common for Java developers, especially becauase they often prefer the TortoiseSVN tool for managing their working copies. If you're publishing content for multiple operating systems, I'd question trying to outsmart people with pre-commit hooks. Sometimes, for example when publishing text documents like README.txt, you need to publish and store documents with the EOL stored for the other OS.
RE: Repository Directory Tree
Giulio- Thanks for the help and the idea. I'm traveling right now (hence my intermittent follow-up on this), but will try it ASAP. Seems like a good idea; I will post results one way or another. Thanks again!! Also, I'll be going through the rest of the follow-up emails on this, too. Thanks to all who responded for the help. Regards, Allen -Original Message- From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] Sent: Tuesday, September 07, 2010 8:20 AM To: anw-d...@infoisland.net; users@subversion.apache.org Subject: RE: Repository Directory Tree > Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 -Original Message- > From: Allen Williams [mailto:alad...@csunv.com] > Sent: 07 September 2010 12:24 > To: users@subversion.apache.org > Subject: RE: Repository Directory Tree > > I *think* that proj1/2/3 are separate projects inside one > repository, but none of those distinctions were very clear to > me (I DID read the manual, cover to cover). I certainly > understand the concept of the equivalence between a directory > and project (I think), but, to me, anyway, it's not clear the > distinction between a repository and further directory structure. > > But now my memory returns: I only created ONE repository, so > all those are projects under that repository. > So /var/svn is a repository, created with svnadmin create /var/svn. The project where imported as var/svn/proj1, var/svn/proj2 and var/svn/proj3. So your projects do live in the var/svn directory in your repository (note there is no / at the beginning so I'm referring to the repository but a directory inside your repository). I would do the following (presuming you're on unix or linux) - check out the whole thing (it might be too big but maybe not) svn checkout file:///var/svn ~/tmp This will create a new directory called tmp in your home directory whit the whole of your repository. Insinde ~/tmp you will have var/svn/proj1, var/svn/proj2 and var/svn/proj3. - move the projects to the root of your repository cd ~/tmp svn move var/svn/proj1 proj1 svn move var/svn/proj2 proj2 svn move var/svn/proj3 proj3 Since you have used svn command the history will be preserved. - commit svn commit -m"Reorganising the projects" Done. Now to see a list of your projects 'svn list file:///var/svn' will be enough. Giulio
Re: svnsync failure when syncing with a repository that used ISO-8859-1 for log messages
On Thu, Sep 9, 2010 at 3:48 AM, Daniel Shahaf wrote:
> CC += dev@, and let me point you to our patch submission guidelines:
> http://subversion.apache.org/docs/community-guide/general.html#patches
>
> Summary for dev@: allow svnsync to translate non-UTF-8 log messages to UTF-8.
>
> (more below)
>
> Daniel Trebbien wrote on Wed, Sep 08, 2010 at 18:58:06 -0700:
>> On Wed, Sep 8, 2010 at 4:39 PM, Daniel Trebbien wrote:
>> > I think that a call to `svn_subst_translate_string`
>> > (http://svn.collab.net/svn-doxygen/svn__subst_8h.html#a29) needs to be
>> > added in the `svnsync_normalize_revprops` function when `propname` is
>> > "svn:log".
>>
>> After applying the following patch to `subversion/svnsync/sync.c`, I
>> can confirm that the "svnsync: Error while replaying commit" error
>> disappears, allowing the sync to complete, and that the problem is
>> indeed a log message encoding issue:
>> diff --git a/subversion/svnsync/sync.c b/subversion/svnsync/sync.c
>> index 8f7be9e..c7a5e38 100644
>> --- a/subversion/svnsync/sync.c
>> +++ b/subversion/svnsync/sync.c
>> @@ -114,6 +114,14 @@ svnsync_normalize_revprops(apr_hash_t *rev_props,
>> /* And count this. */
>> (*normalized_count)++;
>> }
>> +
>> + if (strcmp(propname, "svn:log") == 0)
>> + {
>
> Should this use svn_prop_needs_translation()?
Though it does not appear so, the added lines are within the check for
`svn_prop_needs_translation`.
>> + svn_string_t *new_propval;
>> + SVN_ERR(svn_subst_translate_string(&new_propval, propval,
>> "ISO-8859-1", pool));
>> + apr_hash_set(rev_props, propname, APR_HASH_KEY_STRING,
>> propval = new_propval);
>
> Please, please, please, no assignment inside a function call.
> ^
Fixed
>> + (*normalized_count)++;
>> + }
>> }
>> }
>> return SVN_NO_ERROR;
>>
>>
>> Here I hard-coded the encoding, but I think that the encoding to use
>> should be retrieved from the Subversion config file. Now the questions
>> are:
>>
>> 1. What is the best way to pass the `log-encoding` option of the
>> [miscellany] section to the `svnsync_normalize_revprops` function?
>>
>
> What is 'log-encoding' normally used for? Only for recoding the commit
> message supplied by an editor, right? So I'm not sure we should use it
> here, perhaps a new command-line option will be better. (svnsync
> $subcommand --source-encoding=%s)
I like the idea of adding a command line option, so I think that this
is the way to go.
Do other properties need to be re-encoded, potentially? I was only
thinking about `svn:log`, but perhaps other properties might need
re-encoding as well. If not, then I think that the command line option
should be more specific (e.g.: `--source-log-encoding=%s`).
> And either way, the default behaviour should be to translate nothing.
> (If you always translate from latin1, you break syncs for people who,
> correctly, used UTF-8 log messages the entire time.)
I agree. The default behavior should definitely be to not re-encode
the log messages.
>> 2. Should `svnsync` always store the log messages in UTF-8 even though
>> the original repository log message encoding is different?
>>
>
> You have no choice on the matter: the RA API instructs you to supply it
> a UTF-8 log message. (IIRC, even the libsvn_client API expects an
> already-UTF-8 message.)
>
>> 3. Should there be separate configuration options for the log message
>> encoding of the source repository and the log message encoding of the
>> destination repository?
>
> No, see (2).
>
Another question: which line of code raises the "svnsync: Error while
replaying commit" error message? I would like to try to make this more
helpful.
Subversion Metadata Database Schema
I was wondering if anyone knows of a database schema that exists, preferably for MySQL, which would support all or most of subversion repository metadata? Specifically I was thinking of the current difficulty we have in knowing things like: - how many commits has user U done over the past month - what trees did user U work on last week - which trees have a deploy tag - which trees are tagged with svn:external to path x/y - what files changed inside a subtree from -r A:B The only way I know of to get this information is svn log --verbose | grep some-keyword, however walking a large repository tree takes a lot of time and this requires advanced SVN knowledge. I was thinking of making a cron script, or a post-commit hook, which would add svn metadata to a mysql db so we can make searches against the svn metadata database instantaneous, and create a search UI for non-technical people to perform searches without command line svn experience. I figured a project like this would exist, but I searched both tigris.org projects and the archives and came up empty handed. TIA, Geoff
Two trunks in one repository?
So the concepts of trunks, branches, tags are transparent to SVN. We are in a situation where we might need to have two trunks in one SVN repository. The reason is that we have a family of projects - say ProjectA, ProjectB, ProjectC and so on, each one has it's own repository and have just one trunk (normal setup) since the each of these project has just one part. But now let's say we have a ProjectD which has two sub-systems - PartA and PartB whose code is 95% different. So we are thinking to have two trunks inside the ProjectD repository. We would prefer not to create an individual repository for PartA and PartB because we have decided to categorize each of the repository based on the family of Projects - ProjectA, ProjectB, ProjectC, ProjectD. Just wanted to know to get some thoughts from the experts on this mailing list regarding this setup. Any gotachs I need to watch out for? Thanks!
Re: Two trunks in one repository?
On Thu, Sep 9, 2010 at 8:38 PM, Tech Geek wrote: > So the concepts of trunks, branches, tags are transparent to SVN. We are in > a situation where we might need to have two trunks in one SVN repository. > The reason is that we have a family of projects - say ProjectA, ProjectB, > ProjectC and so on, each one has it's own repository and have just one trunk > (normal setup) since the each of these project has just one part. > > But now let's say we have a ProjectD which has two sub-systems - PartA and > PartB whose code is 95% different. So we are thinking to have two trunks > inside the ProjectD repository. We would prefer not to create an individual > repository for PartA and PartB because we have decided to categorize each of > the repository based on the family of Projects - ProjectA, ProjectB, > ProjectC, ProjectD. > > Just wanted to know to get some thoughts from the experts on this mailing > list regarding this setup. Any gotachs I need to watch out for? > > Thanks! > Maybe I missed something in your scenario, but I would simply have one trunk with PartA and PartB as sub-directories.
Re: Subversion Metadata Database Schema
On 9/9/2010 11:32 AM, Geoff Hoffman wrote: I was wondering if anyone knows of a database schema that exists, preferably for MySQL, which would support all or most of subversion repository metadata? Specifically I was thinking of the current difficulty we have in knowing things like: - how many commits has user U done over the past month - what trees did user U work on last week - which trees have a deploy tag - which trees are tagged with svn:external to path x/y - what files changed inside a subtree from -r A:B The only way I know of to get this information is svn log --verbose | grep some-keyword, however walking a large repository tree takes a lot of time and this requires advanced SVN knowledge. I was thinking of making a cron script, or a post-commit hook, which would add svn metadata to a mysql db so we can make searches against the svn metadata database instantaneous, and create a search UI for non-technical people to perform searches without command line svn experience. I figured a project like this would exist, but I searched both tigris.org projects and the archives and came up empty handed. I don't know if you are interested in a commercial product, but fisheye (http://www.atlassian.com/software/fisheye/) collates a bunch of that data as well as providing full-text search over the repository. -- Les Mikesell lesmikes...@gmail.com
RE: Two trunks in one repository?
On Thu, Sep 9, 2010 at 8:38 PM, Tech Geek wrote: So the concepts of trunks, branches, tags are transparent to SVN. We are in a situation where we might need to have two trunks in one SVN repository. The reason is that we have a family of projects - say ProjectA, ProjectB, ProjectC and so on, each one has it's own repository and have just one trunk (normal setup) since the each of these project has just one part. But now let's say we have a ProjectD which has two sub-systems - PartA and PartB whose code is 95% different. So we are thinking to have two trunks inside the ProjectD repository. We would prefer not to create an individual repository for PartA and PartB because we have decided to categorize each of the repository based on the family of Projects - ProjectA, ProjectB, ProjectC, ProjectD. Just wanted to know to get some thoughts from the experts on this mailing list regarding this setup. Any gotachs I need to watch out for? Thanks! === Maybe I missed something in your scenario, but I would simply have one trunk with PartA and PartB as sub-directories. === That would depend mostly on your branch and merge patterns. I have a similar situation. Since every branch has both projects in it, every workspace that I use to do merges has to check out both projects, even though no merge ever contains changes to both projects. Quite a pain in the rear. To make it worse, the unix developers use filenames that cannot be created on a windows system (e.g. AUX, COM1, and COM4), so we can't do merges on windows systems at all. At my top level I have code, vendors and tools. 'code' contains all of our code, the other two are for imports. So instead of /code/trunk/proj1 and /code/trunk/proj2, I should have /code/proj1/trunk and /code/proj2/trunk. Then I could branch and merge each project separately. But before I do this, I should make absolutelty sure that these two projects have no interdependencies. AFAIK, branches are just names. So above and beyond fixing up your mergeinfo's (if you have any), this should work just fine. JLM
Re: Two trunks in one repository?
On Thu, Sep 9, 2010 at 8:00 PM, Itamar O wrote: > On Thu, Sep 9, 2010 at 8:38 PM, Tech Geek wrote: > >> So the concepts of trunks, branches, tags are transparent to SVN. We are >> in a situation where we might need to have two trunks in one SVN repository. >> The reason is that we have a family of projects - say ProjectA, ProjectB, >> ProjectC and so on, each one has it's own repository and have just one trunk >> (normal setup) since the each of these project has just one part. >> >> But now let's say we have a ProjectD which has two sub-systems - PartA and >> PartB whose code is 95% different. So we are thinking to have two trunks >> inside the ProjectD repository. We would prefer not to create an individual >> repository for PartA and PartB because we have decided to categorize each of >> the repository based on the family of Projects - ProjectA, ProjectB, >> ProjectC, ProjectD. >> >> Just wanted to know to get some thoughts from the experts on this mailing >> list regarding this setup. Any gotachs I need to watch out for? >> >> Thanks! >> > > Maybe I missed something in your scenario, > but I would simply have one trunk with PartA and PartB as sub-directories. > I'm with Itamar ProjectD ProjectD/trunk/PartA ProjectD/trunk/PartB Also, do read up on svn:externals if you haven't already. Cheers / Erik
Re: Two trunks in one repository?
We have hundreds of trees, each with their own trunk/ branches/ tags/ in one SVN repo. Works great. You may want to look at svn:externals. It may require re-thinking how you're using SVN a bit, but the payoff can be big. Basically you branch or tag anything shared, and load it into ProjectD using cd ProjectD svn propset svn:externals local/path path/to/trunk_branch_or_tag When you change files under path/to/trunk_branch_or_tag and svn up ProjectD, changes come streaming in. HTH, Geoff - Original Message - From: "Tech Geek" To: "Subversion Users" Sent: Thursday, September 9, 2010 10:38:51 AM Subject: Two trunks in one repository? So the concepts of trunks, branches, tags are transparent to SVN. We are in a situation where we might need to have two trunks in one SVN repository. The reason is that we have a family of projects - say ProjectA, ProjectB, ProjectC and so on, each one has it's own repository and have just one trunk (normal setup) since the each of these project has just one part. But now let's say we have a ProjectD which has two sub-systems - PartA and PartB whose code is 95% different. So we are thinking to have two trunks inside the ProjectD repository. We would prefer not to create an individual repository for PartA and PartB because we have decided to categorize each of the repository based on the family of Projects - ProjectA, ProjectB, ProjectC, ProjectD. Just wanted to know to get some thoughts from the experts on this mailing list regarding this setup. Any gotachs I need to watch out for? Thanks!
Re: Two trunks in one repository?
On Thu, Sep 9, 2010 at 8:52 PM, Geoff Hoffman wrote: > > We have hundreds of trees, each with their own trunk/ branches/ tags/ in > one SVN repo. Works great. You may want to look at svn:externals. It may > require re-thinking how you're using SVN a bit, but the payoff can be big. > Basically you branch or tag anything shared, and load it into ProjectD using > Something like this? components components/comp1/[branches|tags|trunk] components/comp2/[branches|tags|trunk] components/comp3/[branches|tags|trunk] components/comp4/[branches|tags|trunk] components/comp5/[branches|tags|trunk] projects projects/projA/[branches|tags|trunk] projects/projA/[branches|tags|trunk]/comp1 -> components/comp1/[branches|tags|trunk] (with svn:externals) projects/projB/[branches|tags|trunk] projects/projB/[branches|tags|trunk]/comp2 -> components/comp2/[branches|tags|trunk] (with svn:externals) projects/projC/[branches|tags|trunk] projects/projC/[branches|tags|trunk]/comp3 -> components/comp3/[branches|tags|trunk] (with svn:externals) projects/projD/[branches|tags|trunk] projects/projD/[branches|tags|trunk]/comp4 -> components/comp4/[branches|tags|trunk] (with svn:externals) projects/projD/[branches|tags|trunk]/comp5 -> components/comp5/[branches|tags|trunk] (with svn:externals) Cheers / Erik > > cd ProjectD > svn propset svn:externals local/path path/to/trunk_branch_or_tag > > When you change files under path/to/trunk_branch_or_tag and svn up > ProjectD, changes come streaming in. > > HTH, > > Geoff > > > - Original Message - > From: "Tech Geek" > To: "Subversion Users" > Sent: Thursday, September 9, 2010 10:38:51 AM > Subject: Two trunks in one repository? > > > So the concepts of trunks, branches, tags are transparent to SVN. We are in > a situation where we might need to have two trunks in one SVN repository. > The reason is that we have a family of projects - say ProjectA, ProjectB, > ProjectC and so on, each one has it's own repository and have just one trunk > (normal setup) since the each of these project has just one part. > > But now let's say we have a ProjectD which has two sub-systems - PartA and > PartB whose code is 95% different. So we are thinking to have two trunks > inside the ProjectD repository. We would prefer not to create an individual > repository for PartA and PartB because we have decided to categorize each of > the repository based on the family of Projects - ProjectA, ProjectB, > ProjectC, ProjectD. > > Just wanted to know to get some thoughts from the experts on this mailing > list regarding this setup. Any gotachs I need to watch out for? > > Thanks! > >
Re: Two trunks in one repository?
I am thinking something like this: ProjectD ProjectD/PartA/trunk ProjectD/PartA/tags ProjectD/PartA/branches ProjectD/PartB/trunk ProjectD/PartB/tags ProjectD/PartB/branches Beleive me or not in our scenario the code of Part A and Part B never gets merged at any point. The only common part is that at the end of each release of Part A and Part B their output file is concetenated into a one single file which is then programmed on a hardware part by an external tool. So for a scenario like that I would like to keep it very simple. Any feedback or comments regarding the above structure? Thanks!
Re: Two trunks in one repository?
On Thu, Sep 9, 2010 at 11:23 PM, Tech Geek wrote: > I am thinking something like this: > > ProjectD > ProjectD/PartA/trunk > ProjectD/PartA/tags > ProjectD/PartA/branches > ProjectD/PartB/trunk > ProjectD/PartB/tags > ProjectD/PartB/branches > > Beleive me or not in our scenario the code of Part A and Part B never gets > merged at any point. The only common part is that at the end of each release > of Part A and Part B their output file is concetenated into a one single > file which is then programmed on a hardware part by an external tool. > > So for a scenario like that I would like to keep it very simple. Any > feedback or comments regarding the above structure? > > Thanks! > That actually sounds extremely similar to the way I set up repositories for projects in my organization. Different projects are unrelated, so they reside in separate repositories, but every project (which is an embedded-device) has software development and FPGA development, so the layout within the project is exactly what you described: proj/Software/[trunk,branches,tags] proj/FPGA/[trunk,branches,tags] If you case is similar, I recommend using the layout you described, and considering the following points: * Add proj/Tools (or something like that) to manage the scripts that concatenate the final image etc. * If you also use SVN to store the resulting images (we do, although it is usually not recommended to keep binary outputs in source control), consider adding proj/Releases for those. * If you have code-reuse between projects (we have reusable software modules and IP cores) - look into svn:externals and decide how to manage it in your set up. I haven't completed handling this in my set up (still in the process of migrating from VSS..), but I plan to have a dedicated repository for "shared assets" and have specific projects define the assets they use based on absolute svn:externals.
Re: Two trunks in one repository?
Itamar O, yes you are almost there, I have to say very intelligent guess. I am indeed talking about FPGA development. The only difference is we have a 2 part FPGA on our embedded board. PartA and PartB are both FPGA codes which are developed separately for their respective chips and then later they are concatenated into one single file which is then programmed by the vendor tool on our boards. Concatenation is also not a problem since that is done externally. The only major issue is how do we store (keep in mind SVN principles of trunk, branches, tags) the concatenated file (yes we need to store binary objects too) in my proposed repostiroy structure? I would like this to be as simple as it can be because the developers/users of this system are not very SVN savvy. Thanks! On Thu, Sep 9, 2010 at 1:43 PM, Itamar O wrote: > On Thu, Sep 9, 2010 at 11:23 PM, Tech Geek wrote: > >> I am thinking something like this: >> >> ProjectD >> ProjectD/PartA/trunk >> ProjectD/PartA/tags >> ProjectD/PartA/branches >> ProjectD/PartB/trunk >> ProjectD/PartB/tags >> ProjectD/PartB/branches >> >> Beleive me or not in our scenario the code of Part A and Part B never gets >> merged at any point. The only common part is that at the end of each release >> of Part A and Part B their output file is concetenated into a one single >> file which is then programmed on a hardware part by an external tool. >> >> So for a scenario like that I would like to keep it very simple. Any >> feedback or comments regarding the above structure? >> >> Thanks! >> > > That actually sounds extremely similar to the way I set up repositories for > projects in my organization. > Different projects are unrelated, so they reside in separate repositories, > but every project (which is an embedded-device) has software development > and FPGA development, > so the layout within the project is exactly what you described: > proj/Software/[trunk,branches,tags] > proj/FPGA/[trunk,branches,tags] > > If you case is similar, I recommend using the layout you described, and > considering the following points: > * Add proj/Tools (or something like that) to manage the scripts that > concatenate the final image etc. > * If you also use SVN to store the resulting images (we do, although it is > usually not recommended to keep binary outputs in source control), consider > adding proj/Releases for those. > * If you have code-reuse between projects (we have reusable software > modules and IP cores) - look into svn:externals and decide how to manage it > in your set up. I haven't completed handling this in my set up (still in the > process of migrating from VSS..), but I plan to have a dedicated repository > for "shared assets" and have specific projects define the assets they use > based on absolute svn:externals. >
Re: Two trunks in one repository?
SVN won't care, but our IDE may not like it like that. The only reason I brought up svn:externals before is if PartA and PartB are already in SVN as their own repos (or trees under one repo) then ProjectD doesn't want a copy of those projects code, but rather a reference to them. Thus, on ProjectD you'd have svn propset svn:externals PartA ProjectA/tags/tagA1 PartB ProjectB/tags/tagB1 When you commit and update this, new folders appear (PartA and PartB) from svn checkout of tagA1 and tagB1 respectively. Update those tags or change externals to new tag, and your ProjectD gets the update at next svn up. - Original Message - From: "Tech Geek" To: "Erik Andersson" Cc: "Geoff Hoffman" , users@subversion.apache.org Sent: Thursday, September 9, 2010 1:23:27 PM Subject: Re: Two trunks in one repository? I am thinking something like this: ProjectD ProjectD/PartA/trunk ProjectD/PartA/tags ProjectD/PartA/branches ProjectD/PartB/trunk ProjectD/PartB/tags ProjectD/PartB/branches Beleive me or not in our scenario the code of Part A and Part B never gets merged at any point. The only common part is that at the end of each release of Part A and Part B their output file is concetenated into a one single file which is then programmed on a hardware part by an external tool. So for a scenario like that I would like to keep it very simple. Any feedback or comments regarding the above structure? Thanks!
Re: Two trunks in one repository?
Geoff, I think I am beginning to undestand what you are suggesting. Right now I am in process of implementing this setup. At this point nothing exits - no ProjectD, no PartA and no PartB. So I will try to summarize what I have undestood so far: 1. All our SVN repositories lives under the following location: \\myserver\SVN_Repositories\ProjectA \\myserver\SVN_Repositories\ProjectB \\myserver\SVN_Repositories\ProjectC 2. Now each of the Project directories - Project A, Project B and Project C are SVN repositories of their own (TortoiseSVN->Create Repository here) 3. Now Mr. ProjectD comes along with has two sub-parts - PartA and PartB. So I create a new repository ProjectD (TortoiseSVN->Create Repository here) under this (correct?): \\myserver\SVN_Repositories\ProjectD and then create two directories (with their own tags, branches and trunk) underneath ProjectD (all using SVN commands) like this: \\myserver\SVN_Repositories\ProjectD\PartA\trunk \\myserver\SVN_Repositories\ProjectD\PartA\tags \\myserver\SVN_Repositories\ProjectD\PartA\branches \\myserver\SVN_Repositories\ProjectD\PartB\trunk \\myserver\SVN_Repositories\ProjectD\PartB\tags \\myserver\SVN_Repositories\ProjectD\PartB\branches Note that Part A and Part B are not their individual repositories. They are just directories that live under ProjectD which is a repository. 4. Let's say now PartA and PartB code development begings and at some point a tag is created for each of their release: \\myserver\SVN_Repositories\ProjectD\PartA\tags\REL-1.0 \\myserver\SVN_Repositories\ProjectD\PartB\tags\REL-1.0 Now let's say the output of Part A - PartA.xcf and output of Part B - PartB.xcf are concatenated into a file called PartAB-R1.xcf. My questions: Q1. At this point I would somehow like to store this file (PartAB-R1.xcf) into my SVN repository (ProjectD). What would be an ideal location (logically) to store such a file. Should I be doing any kind of merging from tags (REL1.0) of PartA and PartB to create another node called "Combined-REL-1.0" or something like that. I would like to avoid this if possible. Q2. Also when somebody checks out ProjectD I would like that it pulls the PartA and PartB revision history also so that users cab see the "Revision Graph" of PartA and PartB together using the TortoiseSVN client. I hope I am able to describe the whole scenario to you all.
Re: Two trunks in one repository?
On Fri, Sep 10, 2010 at 12:36 AM, Tech Geek wrote: > Geoff, > > I think I am beginning to undestand what you are suggesting. > > Right now I am in process of implementing this setup. At this point nothing > exits - no ProjectD, no PartA and no PartB. So I will try to summarize what > I have undestood so far: > > 1. All our SVN repositories lives under the following location: > \\myserver\SVN_Repositories\ProjectA > \\myserver\SVN_Repositories\ProjectB > \\myserver\SVN_Repositories\ProjectC > > 2. Now each of the Project directories - Project A, Project B and Project C > are SVN repositories of their own (TortoiseSVN->Create Repository here) > > 3. Now Mr. ProjectD comes along with has two sub-parts - PartA and PartB. > So I create a new repository ProjectD (TortoiseSVN->Create Repository here) > under this (correct?): > \\myserver\SVN_Repositories\ProjectD > and then create two directories (with their own tags, branches and > trunk) underneath ProjectD (all using SVN commands) like this: > \\myserver\SVN_Repositories\ProjectD\PartA\trunk > \\myserver\SVN_Repositories\ProjectD\PartA\tags > \\myserver\SVN_Repositories\ProjectD\PartA\branches > \\myserver\SVN_Repositories\ProjectD\PartB\trunk > \\myserver\SVN_Repositories\ProjectD\PartB\tags > \\myserver\SVN_Repositories\ProjectD\PartB\branches > > Note that Part A and Part B are not their individual repositories. They are > just directories that live under ProjectD which is a repository. > so far all good. > > 4. Let's say now PartA and PartB code development begings and at some point > a tag is created for each of their release: > \\myserver\SVN_Repositories\ProjectD\PartA\tags\REL-1.0 > \\myserver\SVN_Repositories\ProjectD\PartB\tags\REL-1.0 > > Now let's say the output of Part A - PartA.xcf and output of Part B - > PartB.xcf are concatenated into a file called PartAB-R1.xcf. > > My questions: > Q1. At this point I would somehow like to store this file > (PartAB-R1.xcf) into my SVN repository (ProjectD). What would be an ideal > location (logically) to store such a file. Should I be doing any kind of > merging from tags (REL1.0) of PartA and PartB to create another node called > "Combined-REL-1.0" or something like that. I would like to avoid this if > possible. > this is where the ProjectD/Releases I suggested earlier becomes useful. what I would have done for the 1.0 release: 1. tag the PartA & PartB as you described in step 4, 2. create ProjectD/Releases/REL-1.0 directory, 3. create ProjectD/Releases/REL-1.0/sources directory and set svn:externals on this directory to something like: /PartA/tags/REL-1.0 PartA /PartB/tags/REL-1.0 PartB 4. create ProjectD/Releases/REL-1.0/binaries directory and import PartA.xcf, PartB.xcf & PartAB-R1.xcf into it this feels pretty intuitive to me. and it's also a good process to automate (release-management-script). > Q2. Also when somebody checks out ProjectD I would like that it pulls the > PartA and PartB revision history also so that users cab see the "Revision > Graph" of PartA and PartB together using the TortoiseSVN client. > In SVN a working copy does not include the revision history, which remains on the server (as opposed to Git or Hg). In order to see a revision graph (TortoiseSVN feature), you need to communicate with the repository. In fact, you don't even need a working copy in order to enter the TortoiseSVN "Repo browser" and view the revision graph. > > I hope I am able to describe the whole scenario to you all. >
Re: Two trunks in one repository?
svn:externals are exactly what you want. Basically, treat PartA and PartB as separate projects entirely - think third party libraries - then your ProjectD just brings together PartA and PartB and adds the glue to concat them together, using svn:externals to bring in the appropriate versions. Your ProjectD trunk could bring the trunks for the PartA and PartB, and branches could bring in the appropriate branches, with tags being locked to specific releases. Though I would suggest that you also lock trunk to specific releases of the externals too, for stability; but that's a project admin's decision. Ben - Original Message > From: Geoff Hoffman > To: users@subversion.apache.org > Sent: Thu, September 9, 2010 5:12:52 PM > Subject: Re: Two trunks in one repository? > > SVN won't care, but our IDE may not like it like that. The only reason I >brought up svn:externals before is if PartA and PartB are already in SVN as >their own repos (or trees under one repo) then ProjectD doesn't want a copy >of >those projects code, but rather a reference to them. > > Thus, on ProjectD you'd have > > svn propset svn:externals PartA ProjectA/tags/tagA1 PartB ProjectB/tags/tagB1 > > When you commit and update this, new folders appear (PartA and PartB) from > svn >checkout of tagA1 and tagB1 respectively. Update those tags or change >externals >to new tag, and your ProjectD gets the update at next svn up. > > > > - Original Message - > From: "Tech Geek" > To: "Erik Andersson" > Cc: "Geoff Hoffman" , users@subversion.apache.org > Sent: Thursday, September 9, 2010 1:23:27 PM > Subject: Re: Two trunks in one repository? > > > I am thinking something like this: > > ProjectD > ProjectD/PartA/trunk > ProjectD/PartA/tags > ProjectD/PartA/branches > ProjectD/PartB/trunk > ProjectD/PartB/tags > ProjectD/PartB/branches > > Beleive me or not in our scenario the code of Part A and Part B never gets >merged at any point. The only common part is that at the end of each release >of >Part A and Part B their output file is concetenated into a one single file >which is then programmed on a hardware part by an external tool. > > > So for a scenario like that I would like to keep it very simple. Any > feedback >or comments regarding the above structure? > > > Thanks! >
Re: Two trunks in one repository?
>In SVN a working copy does not include the revision history, which remains on the server (as opposed to Git or Hg). Yes. I am aware of that. > In order to see a revision graph (TortoiseSVN feature), you need to communicate with the repository. Yes. True. >In fact, you don't even need a working copy in order to enter the TortoiseSVN "Repo browser" and view the revision graph. In this case I have to view the "Revision Graph" individually for PartA and PartB. In fact I just tried creating the setup (not using externals so far) that I described in my last post and I do not get the "Revision Graph" option when I right click on "ProjectD" repository under the TortoiseSVN->Repo-Browser. However I do get the "Revision Graph" option when I right-click on PartA and PartB individually. I would like to see the "Revision Graph" of both the PartA and PartB together so that the one can get an overview of the entire project in just one snapshot. Is this possible?
Re: Two trunks in one repository?
For some reasons this message was returned to me by the mailer daemon. So resending it again. >In SVN a working copy does not include the revision history, which remains on the server (as opposed to Git or Hg). Yes. I am aware of that. > In order to see a revision graph (TortoiseSVN feature), you need to communicate with the repository. Yes. True. >In fact, you don't even need a working copy in order to enter the TortoiseSVN "Repo browser" and view the revision graph. In this case I have to view the "Revision Graph" individually for PartA and PartB. In fact I just tried creating the setup (not using externals so far) that I described in my last post and I do not get the "Revision Graph" option when I right click on "ProjectD" repository under the TortoiseSVN->Repo-Browser. However I do get the "Revision Graph" option when I right-click on PartA and PartB individually. I would like to see the "Revision Graph" of both the PartA and PartB together so that the one can get an overview of the entire project in just one snapshot. Is this possible?
Does svn merge --reintegrate ^URL syntax really work ?
Hi, I'm learning Subversion via svn-book, I encountered a problem in section "Reintegrating a Branch": http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate In this section, it use the following syntax: svn merge --reintegrate ^/branches/my-calc-branch But when I try it, it always report an error: E:\Incoming\svntest\calc\trunk>svn merge ^../branches/my-calc-branch --reintegrate svn: 不能打开文件“file:///E:/SVNRepository/svntest/calc/branches/.svn/entries”: 文件名、目录名或卷标语法不正确。 (can't open file "file:///E:/SVNRepository/svntest/calc/branches/.svn/entries": File name、Directory name or volume syntax incorrect) Then I try full URL syntax (which is in svn-book-1.5), it works. E:\Incoming\svntest\calc\trunk>svn merge --reintegrate file:///E:/SVNRepository/svntest/calc/branches/my-calc-branch --- 正在合并版本库 URL 之间的差异到 “.”： Uint.c U . I search the svn log of svn-book, I found this syntax was changed in svn-book-r3383: "Modify ch01 and ch04 to use new ^ URL syntax. (Issue #23.)" So, does svn merge --reintegrate ^URL syntax really work ? -- View this message in context: http://old.nabble.com/Does-svn-merge---reintegrate-%5EURL-syntax-really-work---tp29673121p29673121.html Sent from the Subversion Users mailing list archive at Nabble.com.
Checkout exclude pattern
I use subversion to remotely participate in a project with gigs of frequently-changing files that never affect me, mostly images and localizations. Subversion would be perfect for me if only svn checkout had a sticky --exclude option analagous to the current working of sparse directories. No, --set-depth itself doesn't do what I want, there are several thousand directories, and I need the entire tree. Could I please get a few hundred "me too" replies so I can make it an official feature request?
Re: Does svn merge --reintegrate ^URL syntax really work ?
10 sep 2010 kl. 04:16 skrev LiuYan 刘研 : > > Hi, > > I'm learning Subversion via svn-book, I encountered a problem in section > "Reintegrating a Branch": > http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate > > In this section, it use the following syntax: > svn merge --reintegrate ^/branches/my-calc-branch > > But when I try it, it always report an error: > E:\Incoming\svntest\calc\trunk>svn merge ^../branches/my-calc-branch > --reintegrate Don't mix ^ with .. > > svn: 不能打开文件“file:///E:/SVNRepository/svntest/calc/branches/.svn/entries”: > 文件名、目录名或卷标语法不正确。 > (can't open file > "file:///E:/SVNRepository/svntest/calc/branches/.svn/entries": File > name、Directory name or volume syntax incorrect) > > Then I try full URL syntax (which is in svn-book-1.5), it works. > E:\Incoming\svntest\calc\trunk>svn merge --reintegrate > file:///E:/SVNRepository/svntest/calc/branches/my-calc-branch > --- 正在合并版本库 URL 之间的差异到 “.”： > Uint.c > U . > > > I search the svn log of svn-book, I found this syntax was changed in > svn-book-r3383: > "Modify ch01 and ch04 to use new ^ URL syntax. (Issue #23.)" > > So, does svn merge --reintegrate ^URL syntax really work ? > -- > View this message in context: > http://old.nabble.com/Does-svn-merge---reintegrate-%5EURL-syntax-really-work---tp29673121p29673121.html > Sent from the Subversion Users mailing list archive at Nabble.com. >
Re: Repository Directory Tree
Giulio Troccoli wrote: >[...] >- check out the whole thing (it might be too big but maybe not) > svn checkout file:///var/svn ~/tmp >This will create a new directory called tmp in your home directory whit the >whole of your repository. >Insinde ~/tmp you will have var/svn/proj1, var/svn/proj2 and var/svn/proj3. > >- move the projects to the root of your repository > cd ~/tmp > svn move var/svn/proj1 proj1 > svn move var/svn/proj2 proj2 > svn move var/svn/proj3 proj3 >Since you have used svn command the history will be preserved. > >- commit > svn commit -m"Reorganising the projects" if you don't want to check-out the whole repository, and are working from the command line anyway, you can use svnmucc to do the restructuring in one commit without a working copy. svnmucc mv url1 url2 mv url3 url4 ... -- Lorenz
