edited file on the same system (running an X
desktop) as the updated and possibly slightly different copy it is
fairly easy to identify and copy over your changes and make any other
needed additional edits.
--
Les Mikesell
lesmikes...@gmail.com
ere the wandisco 1.8.x rpms would
just drop in and work and we'd be good for several more years with
minimal changes to the configuration.
Thanks for commenting, though - I'm still trying to understand all of
the options.
--
Les Mikesell
lesmikes...@gmail.com
A custom apache may be what it takes to work around the problem. I
was hoping to avoid that since I run several other web services on the
same host.
--
Les Mikesell
lesmikes...@gmail.com
On Thu, May 21, 2015 at 1:38 AM, Ignacio González (Eliop)
wrote:
> Les, I´ve installad Collabnet Subversion Edge 4.0.13 over CentOS 7 (miminal
> ISO) and works fine.
Thanks - does this include a working mod_dav_svn for http access using apache?
--
Les Mikesell
lesmikes...@gmail.com
On Tue, Apr 28, 2015 at 4:37 PM, Les Mikesell wrote:
>
>>> Can someone comment on the best version of subversion to run on
>>> CentOS7? The distribution supplies 1.7.14.I was thinking of
>>> using the packaged 1.8.x from Wandisco, but I don't s
#x27;s history. If there have been deletions/moves
they may be different things. Usually path@rev is what you expect.
--
Les Mikesell
lesmikes...@gmail.com
On Tue, Apr 28, 2015 at 4:06 PM, Nico Kadel-Garcia wrote:
> On Tue, Apr 28, 2015 at 2:15 PM, Les Mikesell wrote:
>> Can someone comment on the best version of subversion to run on
>> CentOS7? The distribution supplies 1.7.14.I was thinking of
>> using the packaged 1.8
is a problem building it or am I missing something?
--
Les Mikesell
lesmikes...@gmail.com
't think it would change much to do a merge from
>> trunk into the previous production workspace there, and publish by
>> committing to production.
>
> most of the commits are using direct repository actions. There are a couple
> actions that do a sparse checkout for an action.
On Tue, Mar 17, 2015 at 9:45 PM, Les Mikesell wrote:
Sorry - accidentally sent before finished...
> On Tue, Mar 17, 2015 at 8:21 AM, Lathan Bidwell wrote:
>>
>>>
>> Also, these publishes are not like putting out a full release of a software
>> package. The en
ad of hoping a a merge ends
>> up with the changes you wanted. And along those lines it is possible
>> to have things in your staging/preview workspace that aren't even
>> committed if you aren't careful about it. Copy to tag/preview
>> tag/switch production to tag/ is a safer approach to be sure no
>> uncommitted changes happen in between.
>
>
> You are correct in why I have not used merge for this operation before.
>
> My preview runs off my trunk branch, so when they preview they see most up
> to date (albeit unpublished) version.
>>
>>
>> --
>>Les Mikesell
>> lesmikes...@gmail.com
>>
>
>
about to be pushed to production instead of hoping a a merge ends
up with the changes you wanted. And along those lines it is possible
to have things in your staging/preview workspace that aren't even
committed if you aren't careful about it. Copy to tag/preview
tag/switch production to tag/ is a safer approach to be sure no
uncommitted changes happen in between.
--
Les Mikesell
lesmikes...@gmail.com
g them
> separate enough to make changes to /trunk/ and not touch /prod/ (until the
> next publish).
> I need to be able to stage changes and preview them (preview server runs off
> the /trunk/ branch).
Alternatively, you could merge the trunk changes into your preview
workspace and commit that to production, with the edits actually being
done elsewhere.
--
Les Mikesell
lesmikes...@gmail.com.
tion web server, and then sometimes takes longer to
>> > re-download all the content (some folders have some decent media, about
>> > 15-30 gig).
Don't you really want to just 'svn switch' your production workspace
to the new production target url instead of del
ink
the apr* part has to match your apache build.
--
Les Mikesell
lesmikes...@gmail.com
and either
the stock older subversion or a packaged newer one like wandisco's.
Is there any chance of getting RHEL7 as your base system? That
shouldn't be horribly outdated at this point. You didn't say what
version you have, but mixing httpd 2.2 with new custom stuff seems
like asking for trouble.
--
Les Mikesell
lesmikes...@gmail.com
not the other way around. Taking a step back, why are you
compiling your own server? Isn't there a packaged version available
for your platform? It might help to start with a known-working
server build.
--
Les Mikesell
lesmikes...@gmail.com
ts become obsolete so getting rid of or archiving that
part would be easy if you had used the 'directory of repositories'
approach instead of 'repository of projects' and everything would have
worked about the same.
--
Les Mikesell
lesmikes...@gmail.com
is time to change the request from 'obliterate' to _any_
reasonable way to fix a repository that has accumulated cruft. And a
big warning to new users to put separate projects in separate
repositories from the start because they are too hard to untangle
later. I've considered dump
there. It probably would still be the main topic of conversation
here if everyone had not simply given up hope long ago.
--
Les Mikesell
lesmikes...@gmail.com
numbering scheme - in
which case you might create a newer tag later and ignore earlier
versions. Copies are cheap in subversion and it doesn't hurt to have
extra tags as long as the names are not confusing.
--
Les Mikesell
lesmikes...@gmail.com
path and revisions using the peg
syntax: path@revision.
--
Les Mikesell
lesmikes...@gmail.com
to a different name in the same directory -
and both will retain the previous history to that point, but then you
wouldn't 'switch' to go between them, you would just use their
different names for as long as they co-exist.
--
Les Mikesell
lesmikes...@gmail.com
ch repository and rsync your common config.
--
Les Mikesell
lesmikes...@gmail.com
On Thu, Jan 22, 2015 at 6:30 PM, Ben Reser wrote:
> On 1/22/15 1:00 PM, Les Mikesell wrote:
>> Are there any tools to help find syntax issues or mismatches in paths
>> between an authz file and the associated repo?
> The validate subcommand of svnauthz (1.8 or newer) or svnaut
directory. For source code work, this almost always makes
sense. If you are working on some random collection of individual
files with no natural structure for branch copies it might not.
--
Les Mikesell
lesmikes...@gmail.com
them after the fact?
--
Les Mikesell
lesmikes...@gmail.com
different repositories for that. Just do what you need.
You could even make different 'top level' projects that that pull in
the directories you want via svn external properties. Updating from
the top level would update the whole tree of external references, but
you'd have to commit changes to them separately.
--
Les Mikesell
lesmikes...@gmail.com
here branches/tags are copied (these are mostly arbitrary,
after all) if your administrator can't keep up with your needs.
--
Les Mikesell
lesmikes...@gmail.com
is strictly a client setting. You'll be able to
tell by what the svn add command shows, though. If it isn't taking
them, explicitly putting the filenames on the command line will work
and, at least on unix-like systems you can use wildcards like * */*
*/*/*, etc,. to have the shell expand all the filenames for you.
--
Les Mikesell
lesmikes...@gmail.com
binary build results). You can override
this by explictly doing an 'svn add' of missing files and committing
them, or you can change the client configuration if you want different
default behavior.
--
Les Mikesell
lesmikes...@gmail.com
es an 'svn cat' of every revision of every file
to feed to it's indexer, though.
--
Les Mikesell
lesmikes...@gmail.com
lient was not able to commit larger data. I'll
> upgrade my Tortoise svn client version to latest and try to commit data may
> be with latest version I will be able to commit data on windows machine too.
> I'll update you regarding this shortly.
As a general recommendation
h to do with the tortoise client, so
you probably won't get the best advice about this problem here. But,
make sure you are using the latest tortoise - if the issue is really
in the neon libraries, it looks like neon has been dropped in the 1.8
release:
http://subversion.apache.org/docs/re
braries on the client side.
--
Les Mikesell
lesmikes...@gmail.com
Does the recently announced bash bug:
https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
affect the security of the way people generally configure svn+ssh access?
--
Les Mikesell
lesmikes...@gmail.com
ou are right that
some of the version control systems designed for distributed use might
be better suited to having multiple copies sitting around in different
places in different states like you have to do if you just have files
with some backup copies somewhere - and you are willing to lose
versions if you have a problem with your local copy. Subversion's
strength is in keeping one authoritative copy in a place where it can
be managed better than client's own filesystems.
--
Les Mikesell
lesmikes...@gmail.com
warning about these problems.
--
Les Mikesell
lesmikes...@gmail.com
are intended to have distributed copies - and keep several,
updated frequently. Subversion's real advantage is where you want
one centrally-managed and authoritative copy. But I don't understand
why you "can't" set up a server when the advantages it provides seem
important to you.
--
Les Mikesell
lesmikes...@gmail.com
On Wed, Aug 27, 2014 at 10:08 AM, Zé wrote:
> On 08/27/2014 03:53 PM, Les Mikesell wrote:
>>
>> It's not that you can't use it, just that it can't protect you from
>> the things that can happen through direct file system access. Like
>> accidentally del
On Wed, Aug 27, 2014 at 9:34 AM, Zé wrote:
> On 08/27/2014 01:49 PM, Les Mikesell wrote:
>>
>> It's basically a bad idea to usefile:// access at all for anything
>>
>> that might be used under multiple user ids. Maybe even for a single
>> user...
>
>
tem access. And it's also a bad idea to do
things carelessly as root - programs generally can't second-guess
that.
--
Les Mikesell
lesmikes...@gmail.com
times over the years that we've fallen foul of files not being
> checked in and then only finding out later.
Can you run a script that explicitly 'svn add's all the files by
expanding the list on the command line instead of doing it by
directory tree? That should overrid
es where a
user will be working on one machine or another - which is mostly
transparent to normal applications.. Should there be a difference if
they work on the server hosting the exported partition or will it
still be slow due to locking?
--
Les Mikesell
lesmikes...@gmail.com
at is
exported via nfs or just the clients mounting it remotely?
--
Les Mikesell
lesmikes...@gmail.com
, let alone repository,
> does not fall into that category.
"Mostly read-only" would be a pretty good description of mature
project maintenance - which in my experience is where most developer
time goes.
--
Les Mikesell
lesmikes...@gmail.com
> is concerned.
Working copies are supposed to be throwaway things that can always be
fixed to the last commit by the server. Why wouldn't you want to use
something fast, cheap, and highly buffered for that, even if it is
half baked?
--
Les Mikesell
lesmikes...@gmail.com
ommand
> similar to:
> find . -type d -name "\.svn" | sed 's/\.svn$//' | xargs svn st
>
Is that really easier than setting an external property?
--
Les Mikesell
lesmikes...@gmail.com
isco has a commercial tool to do this across a
larger number of locations.
Or, if groups at different locations normally work on different
components of your project(s), you might split them into different
repositories, using svn externals to pull everything together.
--
Les Mikesell
lesmikes...@gmail.com
On Fri, Dec 13, 2013 at 7:21 AM, Branko Čibej wrote:
> On 12.12.2013 17:18, Les Mikesell wrote:
>> On Thu, Dec 12, 2013 at 4:02 AM, Branko Čibej wrote:
>>>> Some things... But not the things you really need to complete any
>>>> amount of actual work - lik
n to your problem might be.
But it _was_ intended to be a replacement for cvs, which has nowhere
near the client-side resource requirements.
--
Les Mikesell
lesmikes...@gmail.com
On Wed, Dec 11, 2013 at 11:01 PM, Ryan Schmidt
wrote:
>
> On Dec 11, 2013, at 19:19, Les Mikesell wrote:
>
>>>>> Also, it would mean you would need a constant connection to the server to
>>>> use a subversion working copy.
>>
>> That's hardly
consider the accumulation of cruft on a typical
jenkins build server where a large set of projects are built and
rarely removed - you have to allow much more disk space to each build
slave to accommodate the pristine files that don't have a whole lot of
use.
--
Les Mikesell
lesmikes...@gmail.com
the new copy to the server and
let it do the server work? Unless your pending operation is a
revert, in which case you would want that copy from the server.
--
Les Mikesell
lesmikes...@gmail.com
On Wed, Dec 11, 2013 at 12:24 PM, Ben Reser wrote:
> On 12/11/13 9:47 AM, Les Mikesell wrote:
>> Within reasonable limits it doesn't cost anything more to send more
>> network traffic. But the cost of client disks scales up by the
>> number of clients. Sometimes
reasonable limits it doesn't cost anything more to send more
network traffic. But the cost of client disks scales up by the
number of clients. Sometimes you can get by mounting a network disk
into all the clients, but then performance suffers, especially with
windows clients.
--
Les Mikesell
lesmikes...@gmail.com
s probably more
common - but I thought Microsoft had a reasonable NFS these days that
MS-centric admins might be able to set up.
Anyway google turned up a few hits on possibly similar samba issues.
Does adding ,nounix,noserverinfo to the mount options help?
--
Les Mikesell
lesmikes...@gmail.com
uot;if it hurts, don't do it"
things. But maybe it's a version-specific samba bug.
--
Les Mikesell
lesmikes...@gmail.com
doing dmesg before and
> after generating an svn error doesn't show anything new.
Can you run the svnadmin verify on the box with the drives? Maybe it
is just a client/network/mount issue and the things that worked (ls,
etc.) were running from cache. Can you unmount/mount or reboot
t; messages at the times I did the above tests.
It if is a generic linux box 'dmesg' might show it. If it is some
dedicated file server you'll have to find its own diagnostic
procedures.
--
Les Mikesell
lesmikes...@gmail.com
on VFAT, you might be hitting the the 4GB file
size limit.
>
> All that said, if you have that large of a working copy database, I doubt
> you're going to have very good performance using the working copy over a
> network share.
Not to mention what happens if you have linux filenames that differ
only in case.
--
Les Mikesell
lesmikes...@gmail.com
Email,
> but yes I can look in the directory, and I seem to
> see everything I expected
>
> % ls -al /home/phaley/Papers/2011/ArpitVel/SvnPaper
How about 'svnadmin verify /home/phaley/Papers/2011/ArpitVel/SvnPaper'?
Also, does the NAS physically holding the disks have any loggi
to both the trunk
and branch through an upper level directory that ties them together?
--
Les Mikesell
lesmikes...@gmail.com
he newer
tag). This lets your team work on different parts without too much
impact on each other while still being able to build the whole thing
easily.
--
Les Mikesell
lesmikes...@gmail.com
hanges within the project but lose
the old paths? Coming from a cvs background, the idea of the
location of the top level of a project permanently becomes part of its
history was, ummm, surprising.
--
Les Mikesell
lesmikes...@gmail.com
s into neat subdirectories for easy reference. Besides giving
you a way to pull in the changes cleanly, it also gives you a way to
version those points separately and each component can have its own
release/tagging process and the consuming projects can adjust their
references when they are ready.
--
Les Mikesell
lesmikes...@gmail.com
r settings that would be likely to help with the speed?
--
Les Mikesell
lesmikes...@gmail.com
minimize impacts of what others are doing.
Just a matter of whether you want to resolve small conflicts as they
happen with frequent updates/commits (and maybe take advantages of
other's changes sooner rather than later), or do you want to complete
the changes in isolation so you can prove that your version was the
best and should win if there is a conflict?
--
Les Mikesell
lesmikes...@gmail.com
fault, but what you said
could easily be interpreted that way by anyone who had to ask the
question in the first placeYes, people have to set things up,
but there are tools that can help.
--
Les Mikesell
lesmikes...@gmail.com
sults. Expecting one person to never make
a mistake just doesn't always work out.
A general rule can't cover all cases, but in general I think the
longer you let branches diverge with isolated work, the more likely
they are to have conflicting changes that will take extra work to
resolve when you finally do merge.
--
Les Mikesell
lesmikes...@gmail.com
ve complete access to all the data
that account can read (or reach from either side of the connection),
but also note that this is the opposite case, where the connection
origin and tunnel destination are on the 'less secure' side and the
controlling keys are also outside.
--
Les Mikesell
lesmikes...@gmail.com
s always the trick of ssh-ing a command from inside the
firewall to the DMZ box that (a) sets up port-forwarding and (b) runs
the svn command as though the repo is on localhost. Technically, and
from the firewall's point of view, the connection is established
outbound.
--
Les Mikes
y change that requires new
training or human intervention to fix something is never going to win
back that time. Someone who completely understands the current
process and user base might be able to optimize and improve it with
drastic changes, but that seems unlikely if they are asking for advice
on a mail list.
--
Les Mikesell
lesmikes...@gmail.com
ltiple repos.)
>
Unless you already have a central authentication source you'll have a
certain tradeoff in complexity between maintaining password control
for multiple repos vs. path-based control in a single one and if there
are external references where different groups use each others'
libraries it can be a little messy either way.
--
Les Mikesell
lesmikes...@gmail.com
x27;t have all these revisions in the first
place.
--
Les Mikesell
lesmikes...@gmail.com
ess control easier, and it looks bad if Alice (who
> should have access to project 1 but not project 2) can see Bob's old
> commit metadata to project 2, even if she can't see the commit bodies
> after the split.
How does this work now in the combined repository?
--
Les Mikesell
lesmikes...@gmail.com
you guess at or expect anything
from. They are only useful in terms of the repository history, and it
doesn't matter if your project runs sequentially or not. If you want
names/numbers that make human sense, you'll be copying to tags for
easier reference anyway.
--
Les Mikesell
lesmikes...@gmail.com
you just need to know what they are.
--
Les Mikesell
lesmikes...@gmail.com
On Sat, Aug 24, 2013 at 2:04 PM, Stefan Sperling wrote:
> On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote:
>> Don't forget that it was subversion, not the user, that created the
>> directory and abandoned it in the first place.
>
> If a previously versione
that was not the scenario
> the person who opened this thread posed.
I'd propose that file conflicts aren't really conflicts if the
contents are identical. And that there should be a way to tell
subversion to go ahead and force overwrites of directories and
identical file contents without, at the same time, telling it to
clobber files with differing data.
--
Les Mikesell
lesmikes...@gmail.com
On Sat, Aug 24, 2013 at 2:48 AM, Branko Čibej wrote:
> On 24.08.2013 03:44, Ryan Schmidt wrote:
>> On Aug 23, 2013, at 13:31, Les Mikesell wrote:
>>
>>> On Fri, Aug 23, 2013 at 1:09 PM, Edwin Castro wrote:
>>>
>>>>> I can't, off the
project1/branches/branchB
> /project1/branches/branchB/dir1/dir2/dir3/fileA
> /project1/tags/tag1
> /project1/tags/tag2
So how do you see this working where your branches have their own sub-levels:
/project1/branches/release/branchA
/project1/branches/qa/branchA
/project1/branches/de
of being deleted during a
switch to a branch without it, I don't think any of those scenarios
are possible. But, you are right that in the general case svn would
have to check for special circumstances and raise conflicts if you
have done something weird.
--
Les Mikesell
lesmikes...@gmail.com
but it would be handy to have a way to force mostly-harmless
operations without overwriting any differing file data.
--
Les Mikesell
lesmikes...@gmail.com
if you had put the local files in after
the switch. Am I missing something? Is there a way to --force that
without also potentially --force'ing files that conflict to be
clobbered?
--
Les Mikesell
lesmikes...@gmail.com
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
>>b
nd if you can't do a
matching build on a clean machine from a clean checkout, you won't
ever know how much magic was involved.
--
Les Mikesell
lesmikes...@gmail.com
ake a one-time effort to find the files and
decide how to handle them (renamed versioned copies, templates, moved
local copies, etc.) but then aside from being able to switch among
banches, you can reproduce a usable working copy.
--
Les Mikesell
lesmikes...@gmail.com
dependently, etc.
But you need to understand that the cruft is yours, not subversion's
and whatever you are doing isn't reproducible.
--
Les Mikesell
lesmikes...@gmail.com
that in the future you can use build automation tools like
jenkins, relying only on the contents of the repository even when the
build happens on a new host. It will simply your life even for manual
operations if you can count on that.
--
Les Mikesell
lesmikes...@gmail.com
ignoring?
Again, a clever developer could probably come up with his own way to
delete files matching some patterns if he really wants that to happen.
--
Les Mikesell
lesmikes...@gmail.com
that is not
supposed to exist after the switch. And the only way svn can fix it
for you is if you clean it up. Svn can't decide which of your files
that it can't recreate for you should disappear. Getting that wrong
would be much worse than presenting a conflict on the directory
h
wanted. A slightly different approach is to version the built
component binaries and access them with externals, but that has its
own issues in multi-platform scenarios.
--
Les Mikesell
lesmikes...@gmail.com
to me. It is a branch as far as subversion
is concerned except perhaps for the convention of naming an upper
directory 'branches'. Or a tag if you don't intend to do additional
changes to that copy. And if you think in terms of 'release'
branches/tags it even makes sense for your usage.
--
Les Mikesell
lesmikes...@gmail.com
on't think there
is a generic solution for that - subversion tracks copy-from history,
but not copy-to.
--
Les Mikesell
lesmikes...@gmail.com
ld be working on branch copies that could diverge,
but I think you lose that by forcing a canonical path for development
(as a tradeoff for knowing where the 'new' work is...).
--
Les Mikesell
lesmikes...@gmail.com
ed be.
>
> Its actually very straight-forward as we intentionally focused on targeting
> non-CM-guru folks.
I'm having a little trouble picturing how you would sanely maintain
(say) a conflicting line of code where 2 projects need the difference
across several revisions whe
; tool help with that? Don't you get
conflicting changes that you'd want branches to help isolate?
--
Les Mikesell
lesmikes...@gmail.com
ggestions.
Depending on your platform and tools, there are times when it works
better to have a remote display to a machine on a network where the
real work happens than to copy everything locally. And if you can
automate with Jenkins, you don't really even need the display for the
build, although you do have to somehow commit your changes to
subversion.
--
Les Mikesell
lesmikes...@gmail.com
don't
have a person waiting.
--
Les Mikesell
lesmikes...@gmail.com
1 - 100 of 631 matches
Mail list logo
