On 18-Aug-11 21:01, Stefan Sperling wrote:
Indeed, multiple copyfroms would be nasty.
But I don't see the need.
I definitely don't need it, I just saw a use in having it.
My idea that you should be able to choose the source was based on a wrong
assumption. Now I realize merges are always asy
On 18-Aug-11 19:05, Daniel Shahaf wrote:
What copyfrom would the single directory have, in the case of an add/add
conflict?
The same as if you resolve an add/add file conflict by manually throwing the two
file contents into one file: you may wish a double copyfrom, to trace back to
both origi
When you revert an addition in your working copy, and the item appeared in a
changelist, the working copy becomes corrupt and you can't ever use the filename
again. I built a maintainer mode version from /branches/1.7.x@1155504 which
balks (after a boring stack trace):
svn: E155016: Co
On 28-May-10 9:13, Holger Schmidt wrote:
I have one repository with the development tree of some templates. Those
templates are exported to projects that might customize the templates.
The copy of the templates is added and committed to the project
repository. In the projects the latest changes i
On 27-May-10 21:03, Erik Huelsmann wrote:
On Thu, May 27, 2010 at 8:55 PM, Stein Somers wrote:
On 26-May-10 23:37, Daniel Becroft wrote:
Now SVN knows the folder is unversioned ...
But only according to the false assumption it made that the folder was
deleted from the repository.
Surely
On 26-May-10 23:37, Daniel Becroft wrote:
The folder is still there, without a .svn folder inside it, and svn
doesn't know what to do with it.
C:\wc>svn st
? log
Now SVN knows the folder is unversioned ...
But only according to the false assumption it made that the folde
On 18-May-10 18:22, Cufi, Carles wrote:
Then I checked out newbranch,
In our series of bleeding obvious questions: you did check out to a new
working copy, right? It would be hard to do otherwise.
On 18-May-10 15:12, Cufi, Carles wrote:
> something relatively similar happening, where svn:mer
I'm in the same environment as you describe, but the only times
svn:mergeinfo mysteriously reappear is when using svn copy, not merges.
On 18-May-10 10:04, Cufi, Carles wrote:
And then the original bunch of 60 odd files get the svn:mergeinfo property
added.
Maybe because amongst the unmerged
Why? The command executed successfully and reported what it did.
"ls /blah-blah ." successfully lists the . directory, but still returns
an error code because of the user error in its first argument.
There may be a reason why svn chooses to almost ignore bad input but
it's a surprise for sur
I suspect I have corrupt mergeinffo but I'm not sure. Does anyone know
how I'd make a determination and what resources are out there to help
fix problems?
I'd make the determination by reading and understanding the mergeinfo
values. They are plain text after all. The resource to read is
http:
bad idea, and should be discouraged. A revision that contains
svn:mergeinfo changes should only contain the file and structure
> changes logically equivalent to the revisions that have been merged.
Sure, but back to Joël's question: that still does not mean SVN can
assume this "merge changset"
This will take care of the recursion:
for /R %f in (*.sql) do svn propdel svn:mime-type "%f"
--
Stein
The post-commit hook starts a single process, and eats its STDOUT.
But you can make that single process into whatever you want. If you hook
script is for instance:
#!/bin/sh
perl watch-file.pl | perl notify.pl
then your hook consists of a shell process and two perl processors
working togethe
but if in the
end what you want a single path like /trunk to show you the timeline of
releases,
And by the way, this is called a "moving tag" in SVN circles (or maybe
everywhere).
--
Stein
I'm not sure if this is what you mean with those commands, but if in the
end what you want a single path like /trunk to show you the timeline of
releases, e.g.
trunk 1789 copy of /tags/XYZ_1.3.0_BUILD32_RELEASE_RC1
trunk 1234 copy of /tags/XYZ_1.2.0_BUILD24_RELEASE_RC1
trunk copy of /tags/
One way to get mergeinfo on non-mergeinfo nodes is when you copy a
directory.
E.g. the repository has /trunk/dirA, without mergeinfo anywhere below
/trunk. In a working copy on /trunk do:
svn copy ^/trunk/dirA dirB
Now dirB has mergeinfo that is not helping in any way.
If you do ins
Just be aware that these hooks disallow all commits, not just commits of
merges, where the svnbook advice applies. There's not much better you
can do, because it's impossible to tell from an "old" transaction if it
contains a merge or only genuine, original changes.
If you'd still like to allo
On 03/03/2010 16:18, Ryan Schmidt wrote:
You can check the capabilities of the client in a limited way
Limited indeed, as far as I understand. You get the client information
in the start-commit hook. If you want to correlate it with the contents
of the transaction proposed, you have to be in
There was a thread "spam being forwarded from
ad...@subversion.apache.org" at the end of January which was actually
about spam from ad...@subversion.tigris.org).
The address to complain is supposed to be feedback {_AT_} tigris.org
Much easier is to unsubscribe from this spambot by sending an e
I suspect that the external isn't updated automatically for the committer in
this case is it?
I haven't used externals, but I'm willing to bet a fair amount of money
on it. The committer doesn't update any versioned files - neither those
being committed, because they _are_ the new version, no
On second thought, how about this: don't change the transaction, but
keep the VERSION file in a separate repository, that you reference
through svn:external. That way, you don't modify the contents of the
transaction - you just add a second transaction. Of course it's your
responsibility to tie
On 24/02/2010 12:34, Bailey, Darragh wrote:
Is it possible to modify files in a start-commit hook and include them with a
commit?
As far as I know, you can't even tell which files are modified in the
start-commit hook.
You can tell in the pre-commit hook, but its template shouts
# *** N
I don't know how svn log is supposed to work in these cases, since I use
TortoiseSVN for browsing. But it seems to me that the difference between
case (3) and (5) is inconsistent.
Is there a simple method for revealing the revisions at which a
path or object is deleted on the command line
I
Maybe the self-referential mergeinfo I saw was being introduced some other way.
I see some self-refenertial mergeinfo in our /trunk, after lots of
merges to and from. Maybe I explicitly added it with a record-only in
some state of confusion. But it doesn't scare me at all. It would only
matte
On 09/02/2010 12:51, Janosch Scharlipp wrote:
Is the runtime part of the final program, or is it available as a dll in my
os ready to be loaded on program startup?
In build lingo, that sounds: is the runtime statically linked or
dynamically linked? It depends on how the subversion source code
1) I've a file that MUST exist in the repository in its "default"
version
Then forget svn:ignore - it doesn't apply to versioned files.
You could lock the file in each branch where it occurs, or set the
svn:lock property, to make it more difficult for others to tamper with
it. But in my exper
On 02/02/2010 23:34, Dave Purrington wrote:
Marge doesn't have a matching pattern in her global ignores
Hope you are aware that on Windows there are multiple sources for global
ignores including the registry - I don't know the details but there was
a thread about it recently.
--
Stein
Oops sorry, misread the address.
ad...@subversion.apache.org does not spam me.
ad...@subversion.tigris.org started spamming after the old list closed.
--
Stein
I had those too until I sent an empty mail to
users-unsubscr...@subversion.tigris.org
A confirmation of my request was the last I heard of it.
--
Stein
I haven't used svnmerge.py
On 20/01/2010 8:04, Dieter Oberkofler wrote:
1) svnmerge.py did generate an informative commit message listing all the
logs of the merged revisions is generated in a text file, as a suggestion
for a good commit message.
That seems like a workaround for the lack of su
Does anyone know why svn diff doesn't show files created by svn move or
svn copy?
Because a move or copy doesn't change file contents. "svn status" shows
what has changed in general, "svn diff" zooms in on changed file contents.
--
Stein
> one special file should have 777
You can make it 755 by committing the svn:executable property on the
file, but I don't think there is anything similar for pure access control.
--
Stein
I can't answer your question, but I installed the Summersoft packages
listed on subversion.tigris.org using "yum install --nogpgcheck". This
subversion-1.6.6-1 package comes with neon-0.28 and sqlite-3.5.9. So you
can get subversion-1.6.6-1 without sqlite3.4.
--
Stein
It's a useful report in the right hands, but there are many installers
of SVN on many platforms and none are discussed here. All I can tell is
that your installer is for Windows and it doesn't look like one I know.
You should contact the creator of the installer (and mention which
version of Wi
On 12/01/2010 10:40, Ulrich Eckhardt wrote:
Why only merge a part of the initial changeset?
Well, you said I should merge, and I only want a part!
Okay, first of all, I have no question. I just brought this up to
illustrate that excessive mergeinfo exists and you shouldn't assume
you're doin
I have a pre-commit hook to detect mergeinfo
below root, and remove it whenever it occurs
For clarity: the pre-commit hook detects and rejects. The one removing
the mergeinfo is me, using svn propdel.
Someone asked for the hook code, here it is. It's not my submission for
a beauty contest an
"Moving tags" may be the lingu you were looking for.
--
Stein
On 11/01/2010 18:09, Tyler Roscoe wrote:
The usual way to do this is to make the bugfix on trunk and then
cherrypick merge the change from trunk up to your branch.
Sure, in the early stages of the release process, but near or past
D-day, as any decent CMM zero team we switch to panic mode. We
I think SVN wants you to not copy the file/dir but instead to merge the
revision where it was added to the branch.
Interesting idea, but as far as I get it it seems a complicated process:
- In the WC's target directory, merge a part of the changeset that
created (or last moved) the wanted subd
No explanation here, and not the same symptoms, but you're not the only
one struggling with it. I have a pre-commit hook to detect mergeinfo
below root, and remove it whenever it occurs, which is rare. The
repository has only mergeinfo on root directories, merges are done only
on roots, no swit
40 matches
Mail list logo
