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 of
On Thu, Aug 22, 2013 at 1:30 PM, John Maher 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 unversioned fi
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 wrote:
> On Tue, Aug 20, 2013 at 01:16:40PM -0400, James Hanley
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 'merge_from_tru
On Thu, Aug 22, 2013 at 6:30 AM, John Maher 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 subversion w
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 i
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 dire
> -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 i
> > -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
On Thu, Aug 22, 2013 at 11:40 AM, John Maher 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
supposed to exi
On Thu, Aug 22, 2013 at 5:48 PM, John Maher 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 use switch, b
"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 redu
On 8/22/13 7:59 AM, Les Mikesell wrote:
> On Thu, Aug 22, 2013 at 6:30 AM, John Maher 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 unvers
On Thu, Aug 22, 2013 at 12:15 PM, John Maher 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. One of the
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 to
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
> the
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 versio
On Thu, Aug 22, 2013 at 12:43 PM, John Maher 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 a
> tool ma
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 Ma
John Maher 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 library as w
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 v
On Thu, Aug 22, 2013 at 12:52 PM, John Maher 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. This can
> no
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 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 everyone
doesn't agre
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 sw
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 understand
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. Please
ask for clarification if you do not understand. You gave a good
On Aug 22, 2013, at 13:39, John Maher 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.
> Please ask for c
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 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 config
> file,
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 e
On Thu, Aug 22, 2013 at 04:16:49PM -0500, Les Mikesell claimed:
>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 del
On Thu, Aug 22, 2013 at 4:49 PM, Travis Brown wrote:
> On Thu, Aug 22, 2013 at 04:16:49PM -0500, Les Mikesell claimed:
>
>>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 conta
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 dir
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 origi
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 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 appears to
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 rep
> 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 ti
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!
Scott
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!
Scott
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.
>
>
48 matches
Mail list logo
