Thanks for your replies Andrew and Thorsten.
@Andrew there is no need for a svn copy. I do not want to copy a feature in
one branch to another; I wish to keep the code isolated.
And yes I know subversion won't delete unversioned files, I appreciate the info
on how subversion works. Some
On Thu, Aug 22, 2013 at 1:30 PM, John Maher jo...@rotair.com wrote:
Thanks for your replies Andrew and Thorsten.
@Andrew there is no need for a svn copy. I do not want to copy a feature in
one branch to another; I wish to keep the code isolated.
And yes I know subversion won't delete
So other then tar-ing up the WC, there is no way to reproduce local changes
like this on another system? I know the example given is fairly simple,
but it could be very useful.
-Jim
On Tue, Aug 20, 2013 at 3:28 PM, Stefan Sperling s...@elego.de wrote:
On Tue, Aug 20, 2013 at 01:16:40PM -0400,
ie:
svn merge -cl merge_from_trunk https://svn.somerepo.com/project/trunk
#Any items merged in are added to change list merge_from_trunk to
# easily differentiate from local changes that the user does not want to
check in
svn status
M local_file_changes.txt
--- Changelist
On Thu, Aug 22, 2013 at 6:30 AM, John Maher jo...@rotair.com wrote:
@Andrew there is no need for a svn copy. I do not want to copy a feature in
one branch to another; I wish to keep the code isolated.
And yes I know subversion won't delete unversioned files, I appreciate the
info on how
On 8/21/2013 7:13 PM, Geoff Field wrote: I'm keeping the original BDB
repositories, with read-only permissions.
If I really have the need, I can restart Apache 2 with SVN 1.2.3 and
go back to the original repositories. Otherwise, I also have the
option of re-running my batch file (modifying it
Thanks for the reply Les.
Actually I would call the problem the way I am using the tool. Since no one
has provided a better solution there may not be one. Perhaps no one considered
switching between branches where there could exist a directory with unversioned
files in one and not the other.
Guten Tag John Maher,
am Donnerstag, 22. August 2013 um 17:48 schrieben Sie:
Actually I would call the problem the way I am using the tool.
Since no one has provided a better solution there may not be one.
Perhaps no one considered switching between branches where there
could exist a
-Original Message-
From: Thorsten Schöning [mailto:tschoen...@am-soft.de]
Sent: Thursday, August 22, 2013 12:21 PM
To: users@subversion.apache.org
Subject: Re: Switching
How would you like Subversion to work in your case? From my
understanding it breaks down to something
I don't think you even tried Thorsten,
I can easily. There are actually several options.
1) When switching branches don't raise a conflict if all the files in the
directory are in the global ignore list. And if all that exists in a directory
are files to be ignored it makes logical sense to
-Original Message-
From: Thorsten Schöning [mailto:tschoen...@am-soft.de]
Sent: Thursday, August 22, 2013 12:21 PM
To: users@subversion.apache.org
Subject: Re: Switching
How would you like Subversion to work in your case? From my
understanding it breaks down to something
On Thu, Aug 22, 2013 at 11:40 AM, John Maher jo...@rotair.com wrote:
I don't think you even tried Thorsten,
I can easily. There are actually several options.
How about just 'delete the spurious unversioned files yourself'? The
problem is the versioned directory containing them that is not
On Thu, Aug 22, 2013 at 5:48 PM, John Maher jo...@rotair.com wrote:
Actually I would call the problem the way I am using the tool. Since no one
has provided a better solution there may not be one. ...
Did you read my previous mail in this thread? IMO a better solution in
your case is not to
How about just 'delete the spurious unversioned files yourself'?
As I said in the previous reply, two of those files are user settings. They
would have to be constantly recreated by the developer. That increases costs.
One of the reasons I wanted some form of source code control was to
On 8/22/13 7:59 AM, Les Mikesell wrote:
On Thu, Aug 22, 2013 at 6:30 AM, John Maher jo...@rotair.com wrote:
@Andrew there is no need for a svn copy. I do not want to copy a feature
in one branch to another; I wish to keep the code isolated.
And yes I know subversion won't delete
On Thu, Aug 22, 2013 at 12:15 PM, John Maher jo...@rotair.com wrote:
How about just 'delete the spurious unversioned files yourself'?
As I said in the previous reply, two of those files are user settings. They
would have to be constantly recreated by the developer. That increases
costs.
Thanks for the reply Johan.
I did not get your previous mail, thanks for re-stating it. That is worth
looking into. I'll see how much I have to change to allow the alternate
directories. Maybe experiment keeping the trunk on the network for backup
purposes and the branches local so as not
Thanks for the reply Edwin.
The clean up script is a good idea but won't work here. We have mostly all
class libraries. One executable. This means to test we need to specify an
application in the project. Some developers use the exe while some use a tool
made just for testing the classes.
-Original Message-
From: John Maher [mailto:jo...@rotair.com]
Sent: Thursday, August 22, 2013 1:34 PM
To: Johan Corveleyn
Cc: Thorsten Schöning; users@subversion.apache.org
Subject: RE: Switching
The problem isn't something in the way, the problem is something is
there when
I'll try to clarify, everyone has their own copy of the tool. They also have
their own copy of their settings. The problem arises because the tool stores
the settings files in the same folder as some code specific files. This can
not be changed. So within a single directory we need to
On Thu, Aug 22, 2013 at 12:43 PM, John Maher jo...@rotair.com wrote:
The clean up script is a good idea but won't work here. We have mostly all
class libraries. One executable. This means to test we need to specify an
application in the project. Some developers use the exe while some use
This happens even if you do not do a build. There is a class library in one
branch but not the other mixed with unversioned files that I can do nothing
about.
-Original Message-
From: Andrew Reedick [mailto:andrew.reed...@cbeyond.net]
Sent: Thursday, August 22, 2013 1:48 PM
To: John
John Maher jo...@rotair.com writes:
I use one folder for my source code (all branches) mainly because of
vendor requirements the code must be run from the same directory. I
have created two branches for two new features. One feature extends
an existing library. The other feature adds a new
You are correct that there will be issues with a fresh checkout. But I can
live with that. The code will not be affected, just the way the code is
tested. Once the developer decides on how they wish to test I do not want to
A) lose those changes or B) step on the choices others have made by
On Thu, Aug 22, 2013 at 12:52 PM, John Maher jo...@rotair.com wrote:
I'll try to clarify, everyone has their own copy of the tool. They also have
their own copy of their settings. The problem arises because the tool stores
the settings files in the same folder as some code specific files.
I agree with Les here on the point about making sure you can automate
the process correctly only with versioned resources. In our CI builds we
have the versioned resources configured so that all tests are executed
every time. Developers execute subsets of tests through their tools and
are expected
On Thu, Aug 22, 2013 at 12:58 PM, John Maher jo...@rotair.com wrote:
You are correct that there will be issues with a fresh checkout. But I can
live with that.
Not caring if you can reproduce a workspace is a bold statement to
make on a version control mail list. Don't be surprised if
On 8/22/13 10:54 AM, John Maher wrote:
This happens even if you do not do a build. There is a class library in one
branch but not the other mixed with unversioned files that I can do nothing
about.
Statements like this make me believe that build system is broken. I
would expect the svn
Again Les, you misunderstand. I have no problems with the workspace. It is
exactly the same for everyone, everytime. Please read carefully before you
respond. It has nothing to do with the build. It is user settings, a config
file, ini file, choose your terminology. If you don't
On Aug 22, 2013, at 13:39, John Maher jo...@rotair.com wrote:
You digress. Not a single one of the compiled libraries lives within the
versioned directories. Please read the question before replying incorrectly.
It has nothing to do with code. It has nothing to do with the build.
You said, and I quote, There is a class library in one branch but not
in the other mixed with unversioned files that I can do nothing about.
I misread that statement to mean you had compiled output committed in
one branch. You seem to be trying to point out that the class library is
not compiled
On 22.08.2013 15:55, James Hanley wrote:
ie:
svn merge -cl merge_from_trunk https://svn.somerepo.com/project/trunk
#Any items merged in are added to change list merge_from_trunk to
# easily differentiate from local changes that the user does not want
to check in
svn status
M
On 8/22/13 6:55 AM, James Hanley wrote:
ie:
svn merge -cl merge_from_trunk https://svn.somerepo.com/project/trunk
#Any items merged in are added to change list merge_from_trunk to
# easily differentiate from local changes that the user does not want
to check in
svn status
M
On Thu, Aug 22, 2013 at 1:34 PM, John Maher jo...@rotair.com wrote:
Again Les, you misunderstand. I have no problems with the workspace. It is
exactly the same for everyone, everytime. Please read carefully before you
respond. It has nothing to do with the build. It is user settings, a
Dear subversion users, developers,
I'm working on a project where we are actively working on many branches.
It works great. Despite all the IDE support I have, as a build and
release engineer, I need to work a lot from command line.
Addressing branches/tags could be a pain from command line
On Thu, Aug 22, 2013 at 04:16:49PM -0500, Les Mikesell claimed:
snip
The contents of the file are irrelevant. The point is that it has to
either be versioned so svn can delete it knowing that you can get it
back, and then delete the containing directory that is really the
issue, or you have to
On Thu, Aug 22, 2013 at 4:49 PM, Travis Brown trav...@travisbrown.ca wrote:
On Thu, Aug 22, 2013 at 04:16:49PM -0500, Les Mikesell claimed:
snip
The contents of the file are irrelevant. The point is that it has to
either be versioned so svn can delete it knowing that you can get it
back, and
On 8/22/13 3:00 PM, Les Mikesell wrote:
Why can svn not, instead, simply interpret an already existing directory
as not a conflict? Certainly if a versioned file would overwrite an
unversioned file of the same name then that is a true conflict because
the content may differ. A directory has
Hi Thomas,
From: Thomas Harold
Sent: Friday, 23 August 2013 1:25 AM
On 8/21/2013 7:13 PM, Geoff Field wrote:
I'm keeping the
original BDB repositories, with read-only permissions.
If I really have the need, I can restart Apache 2 with SVN
1.2.3 and
go back to the original
Laszlo Kishalmi wrote on Thu, Aug 22, 2013 at 23:15:04 +0200:
Implementation ideas:
We put a specific property on project1 folder let's call it
svn:branches for now. Here we could describe the layout of
branches and tags for that part of repository. E.g.:
a) Using
Johan Corveleyn jcor...@gmail.com writes:
Now, playing user's advocate: is there still something useful to do
here? I.e. apparently ra_neon worked fine with the broken servers.
Should ra_serf also be able to handle this, so 1.8 clients can still
work fine with servers 1.6.17?
It
On 8/22/2013 7:11 PM, Geoff Field wrote:
6. Create the repository in svn 1.8.
I'm sure there's an upgrade command that would do it all in-place.
7. Strip permissions on the repository back down to 700, owned by
root:root while we reload the data.
While, or before?
Step 6 created the
From: Thomas Harold
Sent: Friday, 23 August 2013 11:53 AM
On 8/22/2013 7:11 PM, Geoff Field wrote:
Most restores for us took about 5-10 minutes, a few of our
larger repos took a few hours.
I was doing this all in the background via remote login to our SVN server, so I
didn't monitor times.
I have a project that I need to fork (in the same repo):
$ svn cp foo bar
$ svn rm bar/trunk/some_dir
$ svn rm bar/trunk/some_file
$ emacs bart/trunk/other_files
$ svn ci
Segmentation fault: 11
I use the 1.8.1 client from macports:
$ svn --version
svn, version 1.8.1 (r1503906)
compiled Aug 13
Hi all,
I appreciate all the tips and info I've received from my server config
questions. It looks like I need to do much more to secure my server before
tackling he SVN portion. I'm going to take a step back and do that first. If
necessary I'll (re)post once that's complete.
Thanks!
Hi all,
I appreciate all the tips and info I've received from my server config
questions. It looks like I need to do much more to secure my server before
tackling he SVN portion. I'm going to take a step back and do that first. If
necessary I'll (re)post once that's complete.
Thanks!
On 8/22/13 2:15 PM, Laszlo Kishalmi wrote:
I'd propose a -b [--branch] option or extend the meaning of ^ sign for
those commands which can work with URL-s. Extending ˇ would mean
that when used as ^/ it means repository root and using it as ^[branch]
then it would refer to a branch.
How
47 matches
Mail list logo
