Hi list,
I am trying to deny a user access to a certain path in an SVN repository.
According to the documentation this is done by setting the username to empty
like this:
[calc:/branches/calc/bug-142/secret]
harry =
In
http://grokbase.com/t/subversion/users/1019eey8h0/problem-implementing-p
Hi list,
recently I noticed that I cannot view the log while an update of a working
copy is running. It's quite annoying. I wonder if it has always been this
way or if this is new in 1.7. Isn't "svn log" a completely remote operation
without involving the local working copy?
Regards,
André
Hi list,
can I use svnserve in daemon mode (to take advantage of its authorization
mechanisms) and still have the client use an SSH tunnel (probably with
different credentials) to connect to it, so I only have to expose the SSH
port?
I found a post at http://svn.haxx.se/users/archive-2004-12/1413
I would think those two mergeinfos were equivalent, so mergeinfo elision
should remove the mergeinfo on "live/templates/c-physignathus".
# svn propget svn:mergeinfo live
/cm_dev:99-344
/dev:367-578,580
# svn propget svn:mergeinfo live/templates/c-physignathus
/cm_dev/templates/c-physignathus:99-3
Hi list
I am using Subversion with TortoiseSVN over HTTPs.
Now that I access my SVN server in Germany from Thailand and displaying logs
and getting diffs is horribly slow, I wonder if I can enable any kind of
compression?
Regards,
André
Stefan Sperling wrote:
>
> On Tue, Aug 02, 2011 at 03:54:23AM +0200, André Hänsel wrote:
> > I am trying to add an svn:externals definition to a working copy. I
> > set the property on a directory and ran svn update on that directory,
> > but nothing is fetched.
>
I am trying to add an svn:externals definition to a working copy. I set the
property on a directory and ran svn update on that directory, but nothing is
fetched.
I found this article:
http://blogs.gnome.org/johannes/2008/02/20/svnexternals-for-noobs/
However, from other documentation it's unclear
David Brodie wrote:
> it is perfectly fine to remove the mergeinfos on files
> so long as the merginfos are preserved on the root folder, and that merges
> should always be done from the root to prevent mergeinfos from being set
> on individual files.
Yes, as long as the mergeinfo is identical, r
Robin Cull wrote:
> I have been working on this "branch" for several weeks and committing as I
> go. But rather than committing onto a branch I have really been
> committing into a subdirectory of the trunk of the main project which
> contains a duplicate of the project as due to my mistake my re
> > Often I have small changes that apply to a branch and the trunk alike.
> > Of course I cannot do a normal merge because the local change doesn't
> > have a revision number yet.
> >
> > If I copy the change from the branch to the trunk or vice versa and
> > then commit it in one single commit, w
Often I have small changes that apply to a branch and the trunk alike. Of
course I cannot do a normal merge because the local change doesn't have a
revision number yet.
If I copy the change from the branch to the trunk or vice versa and then
commit it in one single commit, will it break merge trac
11 matches
Mail list logo
