Bug when merging to pre-1.5 repositories
Hi!
I'm (now, finally) aware of the fact that svn:mergeinfo only came up with 1.5
but this issue is about the behaviour when this is simply not supported.
Anyway, here's what I did:
1. I have a repository, FSFS, created (or, rather, svnadmin loaded) with a
Subversion 1.4.
2. The commandline client is 1.6, running on Debian.
3. The repository is accessed using a file:// URL.
4. Check out a WC of a branch and change into it.
5. "svn merge -c 1234 --record-only ^/trunk/foo"
What happens is that this actually merged changes into the working copy, or,
rather, it caused conflicts trying to merge them in my case. I understand
that it simply can't do what I'm asking it to do, since the 1.4 repository
doesn't support svn:mergeinfo. However, and that is the issue, I would expect
an error ("can't record mergeinfo, not supported by the repository" or
somesuch). What it definitely shouldn't do is merge anything into my files,
since I explicitly asked it to not make any changes.
Also, but that is a minor issue, I would hope for a warning like "old
repository version, some features might be unavailable". By the way, I simply
ran "svnadmin upgrade" on the repository and now the above works. Do I gain
anything else by running a dump/load cycle?
Cheers!
Uli
--
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/
**
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**
Visit our website at
SVN Statistics
Hi Everyone, I have been asked for some statistics about our code base and am hoping that someone might have had a task for something similar already, and will be able to help me out. Here is the text I was sent - but it is really just a guide - it is more a case of "something" to show as opposed to have any specific item(s). I do have a jar that I downloaded from SourceForge - that provides pretty much what I'm after. Lines of code / Churn, Number of commits etc. But it is based on the entire repository from revision 0:head. The specific request (below) comes from the point of view ; These are stats are from rev xxx - when we started work on the latest version. We don't have a classical "release" branch either - just a forever going trunk, so we can't use anything "path" specific to obtain the requested results either. Anyway - if you have ideas - I would be most grateful, here is the questions I was asked; Added xxx Lines of new code Removed xxx Lines of redundant code Performed more than xxx individual code changes. As always - thanks very much in advance! Gavin.
Re: usage of svn_wc_diff
On Wed, Dec 08, 2010 at 11:59:16PM -0800, JamieEchlin wrote:
>
> Daniel, thank you very much for that, that's incredibly helpful. It
> definitely gives me somewhere to start.
Hope, you'll be able to solve your problem. Here's a script that's a bit
more clean than the previous one. I haven't tested it much at all but it
appears to be able to display added, modified and deleted properties set
on both dirs and files. The '###' lines represents TODO's.
Daniel
#!/usr/bin/env python
import sys
import os
import getopt
try:
my_getopt = getopt.gnu_getop
except AttributeError:
my_getopt = getopt.getopt
import svn.wc
import svn.core
EQUAL_STRING = (
"")
UNDER_STRING = (
"")
def usage_and_exit(retval):
if retval:
out = sys.stderr
else:
out = sys.stdout
out.write("""Usage: %s TARGET
Options:
--help (-h) : Show this usage message
Display the difference between the BASE revision and the changes made in the
working copy. This is just a very basic example script. It doesn't properly
handle revisions or the problems involved in adjusting diff labels. At
present it always prints one diff header for each file or dir that has
property changes. If we'd check for more than property changes - we need to
keep track of when we have printed a diff header. Some files can have both
property and text changes.
""" % (os.path.basename(sys.argv[0])))
sys.exit(retval)
def print_diff_headers(path, rev):
print "Index: %s" % path
print EQUAL_STRING
print "--- %s\t (revision %d)" % (path, rev)
### Here we'd check rev2 against some constant that represents the "working
### copy revision" - it's probably -1.
print "+++ %s\t (working copy)" % path
def props_changed(path, propchanges, originalprops):
print "\nProperty changes on %s" % path
print UNDER_STRING
for (name, value) in propchanges.items():
if originalprops is not None and name in originalprops:
original_value = originalprops[name]
else:
original_value = None
if not (value or original_value) or (value == original_value):
continue
if not original_value:
print "Added: %s" % name
elif not value:
print "Deleted %s" % name
else:
print "Modified %s" % name
### We're ignoring special handling of svn:mergeinfo for now.
### Do we have to handle utf8 conversions here?
if original_value is not None:
print " - %s" % original_value
if value is not None:
print " + %s" % value
def content_changed(path, tmpfile1, tmpfile2, rev1, rev2, mimetype1,
mimetype2):
### TODO: Write this one
pass
def has_regular_prop_changes(props):
if not props:
return False
### For some reason, svn_categorize_props() segfaults
### Shouldn't we only pass the regular_props to props_changed?
for (name, value) in props.items():
(kind, unused_prefix_len) = svn.core.svn_property_kind(name)
if kind == svn.core.svn_prop_regular_kind:
return True
return False
class Callback(svn.wc.DiffCallbacks2):
def file_changed(self, adm_access, path,
tmpfile1, tmpfile2, rev1, rev2,
mimetype1, mimetype2, propchanges,
originalprops):
if has_regular_prop_changes(propchanges):
print_diff_headers(path, rev1)
props_changed(path, propchanges, originalprops)
return (svn.wc.notify_state_unknown, svn.wc.notify_state_unknown)
def file_added(self, adm_access, path, tmpfile1, tmpfile2,
rev1, rev2, mimetype1, mimetype2, propchanges,
originalprops):
return (svn.wc.notify_state_unknown, svn.wc.notify_state_unknown)
def file_deleted(self, adm_access, path, tmpfile1,
tmpfile2, mimetype1, mimetype2, originalprops):
return svn.wc.notify_state_unknown
def dir_added(self, adm_access, path, rev):
return svn.wc.notify_state_unknown
def dir_deleted(self, adm_access, path):
return svn.wc.notify_state_unknown
def dir_props_changed(self, adm_access, path,
propchanges, originalprops):
if has_regular_prop_changes(propchanges):
### How fetch the revision here?
rev = 42
print_diff_headers(path, rev)
props_changed(path, propchanges, originalprops)
return svn.wc.notify_state_unknown
def main():
diff_callbacks = Callback()
depth = svn.core.svn_depth_infinity
# Parse the options
optlist, args = my_getopt(sys.argv[1:], "h", ['help'])
for opt, arg in optlist:
if opt == '--help' or opt == '-h':
usage_and_exit(1)
if le
Re: Periodically merge between trunk->branch and branch->trunk
Daniel Albuschat wrote: I'd like to create a branch from trunk and periodically merge trunk into my branch to stay up to date with what happens in trunk. At some point, the feature in my branch reaches a kind of stability that is OK for trunk, so I merge it back to trunk. The difference to the standard situation is that I want to continue working on the branch, because the feature is not completely finished, yet, or it needs further enhancement. Currently the only solution I see is to reintegrate the branch to trunk and then re-create the branch. This has the shortcoming that all developers working on the branch have to switch to the new branch (although it is the same URL) to be able to work with it, right? This is ok when I'm working alone on my branch, but with a development team, it becomes tricky to make sure that everyone properly switch to the new branch. This is covered in the book: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice -kgd
RE: Periodically merge between trunk->branch and branch->trunk
Moin Daniel, > I'd like to create a branch from trunk and periodically merge trunk > into my branch to stay up to date with what happens in trunk. > At some point, the feature in my branch reaches a kind of stability > that is OK for trunk, so I merge it back to trunk. > The difference to the standard situation is that I want to continue > working on the branch, because the feature is not completely finished, > yet, or it needs further enhancement. A branch can be used after --reintegrate, but why make life more complicated? http://stackoverflow.com/questions/3309602 > Currently the only solution I see is to reintegrate the branch to > trunk and then re-create the branch. This has the shortcoming that all > developers working on the branch have to switch to the new branch > (although it is the same URL) to be able to work with it, right? It shouldn't be the same URL. Append a number you increment each time around: * branches/hubbel * branches/hubbel-2 * branches/hubbel-3 > This is ok when I'm working alone on my branch, but with a development > team, it becomes tricky to make sure that everyone properly switch to > the new branch. Subversion (or any other VC system, for that matter) cannot fully substitute inter-developer communication. Just use a mail distribution list or whatever works for you. Michael
Re: Problem checking out when # in URL
Have you tried replacing the '#' with '%23'? Hth, Nick Stolwijk ~Java Developer~ iPROFS Wagenweg 208 2012 NM Haarlem T +31 23 547 6369 F +31 23 547 6370 I www.iprofs.nl On Thu, Dec 9, 2010 at 12:01 PM, Caroline Warren wrote: > Hi, > > > > I am looking into the possibility of us using Subversion for our source > control and I have encountered a problem using the “svn checkout” command to > checkout from a URL with a # character. I also have tortoiseSVN install and > I do not seem to encounter this problem when I checkout using tortoise. The > only difference I can see is that the version of subversion is 1.6.13 for > the command line client I have installed and the version of subversion is > 1.6.12 on the tortoise client I have installed. The error I am seeing is > shown below. Could you please let me know if you are aware of any problems > using the # character in filenames or have any idea what could be causing > this? > > > > C:\ >svn checkout "http://svn.x.com/svn/its-support/C#Apps"; > "C:\Documents and Settings\C_Warren\My Documents\TestCheckout" > > svn: Server sent unexpected return value (400 Bad Request) in response to > OPTIONS request for 'http://svn.xx.com/svn/its-support/C#Apps' > > > > Kind regards, > > > > Caroline
Periodically merge between trunk->branch and branch->trunk
Hello there, I have to following use-case: I'd like to create a branch from trunk and periodically merge trunk into my branch to stay up to date with what happens in trunk. At some point, the feature in my branch reaches a kind of stability that is OK for trunk, so I merge it back to trunk. The difference to the standard situation is that I want to continue working on the branch, because the feature is not completely finished, yet, or it needs further enhancement. Currently the only solution I see is to reintegrate the branch to trunk and then re-create the branch. This has the shortcoming that all developers working on the branch have to switch to the new branch (although it is the same URL) to be able to work with it, right? This is ok when I'm working alone on my branch, but with a development team, it becomes tricky to make sure that everyone properly switch to the new branch. Here's a drawing: http://dl.dropbox.com/u/1913181/Perm/Subversion-Branch-Remerge-UseCase.png Kind regards, Daniel Albuschat
Problem checking out when # in URL
Hi, I am looking into the possibility of us using Subversion for our source control and I have encountered a problem using the “svn checkout” command to checkout from a URL with a # character. I also have tortoiseSVN install and I do not seem to encounter this problem when I checkout using tortoise. The only difference I can see is that the version of subversion is 1.6.13 for the command line client I have installed and the version of subversion is 1.6.12 on the tortoise client I have installed. The error I am seeing is shown below. Could you please let me know if you are aware of any problems using the # character in filenames or have any idea what could be causing this? C:\ >svn checkout "http://svn.x.com/svn/its-support/C#Apps"; "C:\Documents and Settings\C_Warren\My Documents\TestCheckout" svn: Server sent unexpected return value (400 Bad Request) in response to OPTIONS request for 'http://svn.xx.com/svn/its-support/C#Apps' Kind regards, Caroline
