You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Eric <sp...@scoot.netis.com> on 2006/11/07 01:35:07 UTC
Problems with Limitations or "Differences" of Subversion
I had a rather, uh, spirited discussion with one of my business partners
today about version control systems in general and Subversion in particular.
We have more or less settled on Subversion to handle version control for
all of our documents ... company policy / procedure documents, meeting
agendas and minutes, project specifications, that sort of thing ... in
addition to source code for projects.
And, therein lies at least part of the problem ... there are two aspects of
Subversion's operation that are causing us many problems ... one of which I
can live with (and defend the operation of Subversion in the face of
arguments from my partners) and the other of which I'm not sure that I can.
As we see it, the two main limitations of Subversion are the inability to
check out and check in individual files (you have to do whole directories),
and the fact that the version number for the whole repository increments
whenever you make any change to any one file.
I really can't defend the second issue .. it just seems to me like a wrong
design decision and I can't think of a reason why it's good or why it happened.
But, as for the first, I got to thinking after my partner left to go home
... If you consider that Subversion is primarily for source code control,
then I guess it makes sense to force the checking out of a whole directory
rather than a single file. After all, if you follow the rule that your
code should at least build before you check it in, how can you build it if
you don't have all the rest of the files?
There is a school of thought that says that it is A Very Bad Idea for
programmers to keep local copies of files (after all, what the %%#$ is
version control for??) and that they should, I suppose, strip off all old
copies of the source every time they check something in. I don't buy into
that and it seems the designers of Subversion didn't either ... you keep a
local work copy of the source files, and you update them whenever necessary
with the latest versions from the version-controlled source tree, right?
That works OK for source file sets where each file is related to the
rest. It works a LOT less well in the case of directory trees full of
documents that are related to one another only because they're part of the
same project or part of the collection of policies and procedures for the
same company. If I make a change to the SRS, I don't want the SDD's
version number to bump.
I'm beginning to think we'd be better off using Subversion for source code
control and something else for document control, though it seems
unfortunate that we would have to do that and not use the same tool for both.
How do you all handle this within your companies or projects?
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Wim Coenen <wc...@gmail.com>.
2006/11/7, Eric <sp...@scoot.netis.com>:
> As we see it, the two main limitations of Subversion are the inability to
> check out and check in individual files (you have to do whole directories),
> and the fact that the version number for the whole repository increments
> whenever you make any change to any one file.
>
> I really can't defend the second issue .. it just seems to me like a wrong
> design decision and I can't think of a reason why it's good or why it happened.
You can completely ignore the repository revision if you don't like it. Anywhere
where a revision number is required by the command line client, you can instead
use a date enclosed in curly braces, e.g.
svn checkout --revision {2002-02-17T15:30}.
You can specify any date, and it will be tranlated into the repository revision
which was the HEAD at that (server) time.
If you look at it like this, your critique is a bit like saying:
"I don't like that time continues to pass while I'm not doing
commits on a particular file. Each file should have a seperate
clock."
regards,
Wim.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by Kenneth Porter <sh...@sewingwitch.com>.
On Monday, November 06, 2006 10:56 PM -0500 Andy Levy <an...@gmail.com>
wrote:
> You cannot currently purchase VSS to my knowledge.
When I purchased Visual Studio 2005 a few months ago, VSS was an optional
item I could get. I suspect little if anything was fixed or added. It was
probably just the same product in a different box.
> Merging is not terribly good from what I recall.
VSS uses a merge on commit model, which can be exceedingly dangerous. You
don't know if the code you check in actually works until you check it back
out again.
> The replacement is called Team System IIRC, it's supposedly all new,
> but I know nothing about it.
It was available for a considerable surcharge as part of VS2005 Enterprise.
It includes more functionality, and seemed like a combination of a VCS,
issue tracker, and white board. If you need the additional features you
could also use Subversion plus Trac. I wouldn't rule out Team System, but
research it fully to see if it addresses your issues with Subversion
without introducing new problems.
For more on VSS, you could also look at Microsoft's sourcesafe newsgroups.
<http://groups.google.com/group/microsoft.public.vstudio.sourcesafe>
<http://groups.google.com/group/microsoft.public.sourcesafe>
<http://groups.google.com/group/microsoft.public.visual.sourcesafe>
<http://groups.google.com/group/microsoft.public.vsnet.vss>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by Talden <ta...@gmail.com>.
4 timezones (permanently though people do move about a bit) for us
spread almost at even spacings around the globe.
3 of these teams are constantly working in the same project space.
There's only 8-10 developers in each timezone but we get a fair bit of activity.
Needless to say, minimising the required bandwidth is also important to us.
--
Talden
On 11/8/06, Ron Olson <ta...@gmail.com> wrote:
> Here's an easy one...do any of your developers reside in multiple time
> zones? We discovered that VSS cannot in any way handle the fact that a user
> checked in a file at 8pm, then the same file was checked at 7:30 (because of
> the TZ). Totally corrupts the database. It's documented in Microsoft's KB,
> but I can't find it at the moment.
>
> This one item alone caused us to abandon VSS, though there were plenty of
> others (as mentioned already in this thread).
>
>
> On 11/7/06, Eric < spamsink@scoot.netis.com> wrote:
> > At 11:58 AM 11/7/2006, Jeremy Pereira wrote:
> >
> > >> What about mounting the repository through WebDAV, is that an option?
> >
> > Good afternoon, Jeremy.
> >
> > That's probably an option. I was not able to get that to work initially
> > but I didn't really spend much time on it since everyone who was going to
> > use the repository was happy with SmartSVN and svn+ssh. So, right now
> > that't the only thing that's set up. But I'll look at WebDAV when I get a
> > little free time later this week or next.
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail:
> users-help@subversion.tigris.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by Ron Olson <ta...@gmail.com>.
Here's an easy one...do any of your developers reside in multiple time
zones? We discovered that VSS cannot in any way handle the fact that a user
checked in a file at 8pm, then the same file was checked at 7:30 (because of
the TZ). Totally corrupts the database. It's documented in Microsoft's KB,
but I can't find it at the moment.
This one item alone caused us to abandon VSS, though there were plenty of
others (as mentioned already in this thread).
On 11/7/06, Eric <sp...@scoot.netis.com> wrote:
>
> At 11:58 AM 11/7/2006, Jeremy Pereira wrote:
>
> >> What about mounting the repository through WebDAV, is that an option?
>
> Good afternoon, Jeremy.
>
> That's probably an option. I was not able to get that to work initially
> but I didn't really spend much time on it since everyone who was going to
> use the repository was happy with SmartSVN and svn+ssh. So, right now
> that't the only thing that's set up. But I'll look at WebDAV when I get a
> little free time later this week or next.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Re: Visual Source Safe vs Subversion
Posted by Eric <sp...@scoot.netis.com>.
At 11:58 AM 11/7/2006, Jeremy Pereira wrote:
>> What about mounting the repository through WebDAV, is that an option?
Good afternoon, Jeremy.
That's probably an option. I was not able to get that to work initially
but I didn't really spend much time on it since everyone who was going to
use the repository was happy with SmartSVN and svn+ssh. So, right now
that't the only thing that's set up. But I'll look at WebDAV when I get a
little free time later this week or next.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by Jeremy Pereira <je...@jeremyp.net>.
On 7 Nov 2006, at 15:52, Eric wrote:
> At 10:56 PM 11/6/2006, Andy Levy wrote:
>
> <AL>>>>>That your partner is perturbed by something as
> inconsequential as SVN's revision number scheme while insisting
> upon using VSS makes me nervous for your project and
> organization.<<<<<
>
> Good morning, Andy.
>
> In all fairness to my partner, the revision numbering scheme is a
> minor irritation to him. And, the more I think of it the more I
> see that it makes sense in the case of source code trees or inter-
> related documents, and I think he has no problem with that. His
> main objections revolve around ease of use and the fact that you
> can't check out individual files, and you can't drag-and-drop files
> from the repository into your sandbox, at least not with any of the
> GUIs we've tried such as SmartSVN, TortoiseSVN, or WebSVN.
What about mounting the repository through WebDAV, is that an option?
>
> As for VSS, he owns a copy, it's the system he knows best and so
> there is no learning curve for him. That's why he's pushing it.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by allan juul <al...@muly.dk>.
Eric wrote:
...
> His main objections revolve
> around ease of use and the fact that you can't check out individual
> files ...
eh, is that possible in VSS? i thought you had to have a working
directory (like Subversion)
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by Eric <sp...@scoot.netis.com>.
At 10:56 PM 11/6/2006, Andy Levy wrote:
<AL>>>>>That your partner is perturbed by something as inconsequential as
SVN's revision number scheme while insisting upon using VSS makes me
nervous for your project and organization.<<<<<
Good morning, Andy.
In all fairness to my partner, the revision numbering scheme is a minor
irritation to him. And, the more I think of it the more I see that it
makes sense in the case of source code trees or inter-related documents,
and I think he has no problem with that. His main objections revolve
around ease of use and the fact that you can't check out individual files,
and you can't drag-and-drop files from the repository into your sandbox, at
least not with any of the GUIs we've tried such as SmartSVN, TortoiseSVN,
or WebSVN.
As for VSS, he owns a copy, it's the system he knows best and so there is
no learning curve for him. That's why he's pushing it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by Andy Levy <an...@gmail.com>.
On 11/6/06, Eric <sp...@scoot.netis.com> wrote:
>
> As a followup to "Problems with Limitations or Differences of Subversion"
> posted a short time ago...
>
> One of my partners is pushing really, REALLY hard to convert us over to
> Visual Source Safe and whatever that add-on is (I forget the name, now)
> that supports accessing VSS repositories over the Internet.
>
> I really don't want to do this even if I wanted to spend the $1500 or
> thereabouts that it would cost us to do it, but I don't personally have any
> experience with VSS and so I have no way to present an effective argument.
You cannot currently purchase VSS to my knowledge. The latest release
is closing in on 8 years old now. And without regular and very careful
monitoring, you WILL lose data in it. The database is very easily
corrupted, and backing it up can get tricky because clients maintain a
connection to the database (vs. SVN, which operates in a disconnected
manner).
VSS by default uses locking when working with files. If a user checks
out (locks) a file, then leaves the company or goes on vacation for 2
weeks, an administrator has to manually unlock the file if someone
else needs to work on it, and when that other person comes back,
you've got a merge mess on your hands. Merging is not terribly good
from what I recall.
Intentionally choosing VSS for a new implementation in 2006 (nearly
2007) unless you have tools that absolutely require it and can't work
with any other source control is a very bad idea IMO.
The replacement is called Team System IIRC, it's supposedly all new,
but I know nothing about it.
Kenneth posted some good links on VSS, especially that first one.
That your partner is perturbed by something as inconsequential as
SVN's revision number scheme while insisting upon using VSS makes me
nervous for your project and organization.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by Tim Hill <dr...@comcast.net>.
It's an internal tool called "Source Depot" (internally known as
"source despot" <g>) that is actually a licensed, modified version
of Perforce.
--Tim
On Nov 9, 2006, at 8:09 AM, Ron wrote:
> What does Microsoft use for Version Control? It can't be VSS?
>
> Ron
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by Andy Levy <an...@gmail.com>.
On 11/9/06, Ron <ro...@gmail.com> wrote:
> What does Microsoft use for Version Control? It can't be VSS?
MS hasn't used VSS in a long, long time. At least 7 years from what I
recall when I was doing research on it in 1999. I don't remember what
it was they were using then.
You might be able to find out more on what they're using on some of
the MSDN blogs, but I haven't checked there in a while.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by Martin Tomes <li...@tomes.org>.
> On 11/9/06, *Ron* <ron.gilbert@gmail.com <ma...@gmail.com>>
> wrote:
>
> What does Microsoft use for Version Control? It can't be VSS?
Gaurav Kothiyal wrote:
> I think its clear Case
There are some comments from people who either worked with or had
contact with Microsoft here:
http://www.subversionary.org/propaganda/why-not-vss
Since then team system has appeared, I would hope that Microsoft will be
using it themselves. This is their description of "Visual Studio 2005
Team Foundation Server":
http://msdn.microsoft.com/vstudio/teamsystem/products/tfs/default.aspx
--
Martin Tomes
echo 'martin at tomes x org x uk'\
| sed -e 's/ x /\./g' -e 's/ at /@/'
Visit http://www.subversionary.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by Gaurav Kothiyal <ko...@gmail.com>.
I think its clear Case
On 11/9/06, Ron <ro...@gmail.com> wrote:
>
> What does Microsoft use for Version Control? It can't be VSS?
>
> Ron
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Gaurav Kothiyal
Re: Visual Source Safe vs Subversion
Posted by Ron <ro...@gmail.com>.
What does Microsoft use for Version Control? It can't be VSS?
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by Pieter <pi...@hotmail.com>.
"Eric" <sp...@scoot.netis.com> wrote in message
news:6.2.1.2.0.20061106212432.03142420@shell.mv.net...
> Is there a "VSS vs Subversion vs ???" chart somewhere on the web that
> compares and contrasts?
This one is nice...
http://better-scm.berlios.de/comparison/comparison.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by Kenneth Porter <sh...@sewingwitch.com>.
On Monday, November 06, 2006 9:32 PM -0500 Eric <sp...@scoot.netis.com>
wrote:
> One of my partners is pushing really, REALLY hard to convert us over to
> Visual Source Safe and whatever that add-on is (I forget the name, now)
> that supports accessing VSS repositories over the Internet.
Avoid VSS, even if you don't choose Subversion.
<http://www.highprogrammer.com/alan/windev/sourcesafe.html>
<http://www.developsense.com/testing/VSSDefects.html>
<http://www.wadhome.org/svn_vs_vss.html>
> This is the same partner who objects to the fact that you can't check out
> an individual file or maintain individual version numbers for each file
> (well, in truth, we all object to those, but I can live with them better
> than he can, apparently).
You could also choose a file-oriented version control system, such as RCS.
Another approach is to separate the idea of "document" from the idea of
"file" and store each document as a directory, instead of a file.
One could consider the revision number of that directory to be the number
of commits to it, which could be counted from a "svn log" run. (Is there a
specific SVN command to do that?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by Eric <sp...@scoot.netis.com>.
At 05:30 AM 11/7/2006, Nikki Locke wrote:
<NL>>>>>I used VSS and SourceOffSite (an addon from a different company
which tried to make VSS work remotely). It was _AWFUL_.<<<<<
Good morning, Niki.
Yes, SourceOffSite is the one I was trying to think of, that my partner is
pushing (since we all work remotely and our server is located in an office
building downtown where none of us hardly ever go).
Thanks for the feedback on SOS.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Visual Source Safe vs Subversion
Posted by Nikki Locke <in...@trumphurst.com>.
I used VSS and SourceOffSite (an addon from a different company which tried
to make VSS work remotely). It was _AWFUL_.
VSS occasionally corrupts its database (even if you only use it locally).
There are no tools to recover from this (except to restore from a backup
which was made while no-one was writing to the database).
SourceOffSite is pretty bad. It worked some of the time, but had a tendency
to hang up, and prevent any further access to the repository. This was
almost guaranteed to happen if you tried to check out a large tree
structure of files and folders. [I am pretty sure the problem was with VSS
rather than SOS - SOS uses VSS's object model, which is incomplete and
buggy.]
--
Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
http://www.trumphurst.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Visual Source Safe vs Subversion
Posted by Eric <sp...@scoot.netis.com>.
As a followup to "Problems with Limitations or Differences of Subversion"
posted a short time ago...
One of my partners is pushing really, REALLY hard to convert us over to
Visual Source Safe and whatever that add-on is (I forget the name, now)
that supports accessing VSS repositories over the Internet.
I really don't want to do this even if I wanted to spend the $1500 or
thereabouts that it would cost us to do it, but I don't personally have any
experience with VSS and so I have no way to present an effective argument.
This is the same partner who objects to the fact that you can't check out
an individual file or maintain individual version numbers for each file
(well, in truth, we all object to those, but I can live with them better
than he can, apparently).
Can some of you, especially those of you with experience with VSS, help me
to formulate some arguments against VSS and in favor of Subversion?
(Unfortunately, "VSS is evil" will have seriously limiited effectiveness as
an argument.) :-)
Is there a "VSS vs Subversion vs ???" chart somewhere on the web that
compares and contrasts?
Thanks...
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Eric <sp...@scoot.netis.com>.
At 10:23 PM 11/6/2006, Talden wrote:
<T>>>>>Since, to discover the number of times and when a given file/folder
has been changed you list the revisions in which it was changed. This
means that revisions are relative to one another and that they represent
points in time (without explicitly expressing time). That said, in a
file-system where files are inter-related, per-file revisions mean even
less than the repository revision in Subversion.<<<<<
Good morning, Talden.
Certainly that makes sense when maintaining source code trees. It seems
that it often makes less sense when maintaining documents such as
specifications, which are often independent of one another. Of course,
just as often, they are interdependent with one another, e.g. a test plan
derives from a software requirements spec which derives from a system spec
which derives from a marketing spec.
Some documents are truly independent, though, and it seems a waste to have
to keep each such document in its very own repository.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Talden <ta...@gmail.com>.
On 11/7/06, Ryan Schmidt <su...@ryandesign.com> wrote:
>
> On Nov 6, 2006, at 19:35, Eric wrote:
>
> > As we see it, the two main limitations of Subversion are the
> > inability to check out and check in individual files (you have to
> > do whole directories), and the fact that the version number for the
> > whole repository increments whenever you make any change to any one
> > file.
> >
> > I really can't defend the second issue .. it just seems to me like
> > a wrong design decision and I can't think of a reason why it's good
> > or why it happened.
> [snip]
> > If I make a change to the SRS, I don't want the SDD's version
> > number to bump.
>
> Do not think of it as the version number (or more properly: revision
> number) *of a file* or *of a directory* but instead *of the
> repository*. Attach no further meaning to this number other than "the
> number of changes that have been made to the repository." That's all
> it is.
I think it's more than that. Since, to discover the number of times
and when a given file/folder has been changed you list the revisions
in which it was changed. This means that revisions are relative to
one another and that they represent points in time (without explicitly
expressing time). That said, in a file-system where files are
inter-related, per-file revisions mean even less than the repository
revision in Subversion.
Not being able to follow a path forward through copies/moves
disappoints me (for that matter how cheap is listing revision numbers
for past changes) but I'm never going to worry that the revision
numbers representing when I did change a file aren't consecutive
values. I'd much rather know that two files were changed in the same
revision or that fileX changed after fileY (though preservation of
modification timestamps would ease this issue somewhat).
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
On 11/6/2006 10:12 PM, Eric wrote:
> At 09:24 PM 11/6/2006, Ryan Schmidt wrote:
>
> <RS>>>>>Do not think of it as the version number (or more properly:
> revision number) *of a file* or *of a directory* but instead *of the
> repository*. Attach no further meaning to this number other than "the
> number of changes that have been made to the repository." That's all it
> is.<<<<<
>
> Good evening, Ryan.
>
> Yes, I understand that. But, if the current revision of the SRS is 4.3 (as
> recorded in the change log on the back page of the document), and someone
> comes to me and tells me that he needs revision 4.1 and wants to know how
> he can check it out, what do I tell him if the whole repository is at
> revision 17?
Mark told you what to do when "4.1" is referring to a release of the
whole system: tag it, ignore the rev number.
There's also the situation where you have a number of weakly connected
files, each with it's own version number. In that case, simply record
the revision number of the repository (using the svn:keywords attribute,
if you like) rather than making up your own numbering scheme. The
individual files will have revision numbers like 5, 17, 28, etc: it
shouldn't matter to you that some numbers in the sequence are missing.
> This is aside from the issue about if he wants the SRS he'll have to check
> out everything else in that repository directory including stuff he doesn't
> care about.
He can export individual files if he doesn't mind losing the versioning.
He can check out the whole directory, but update individual files to
specific revisions.
Duncan Murdoch
>
> (I suggested that the only real "fix", in that case, would be to put each
> file into its own repository and I thought I was going to be lynched...) :-(
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Talden <ta...@gmail.com>.
> <RS>>>>>Do not think of it as the version number (or more properly:
> revision number) *of a file* or *of a directory* but instead *of the
> repository*. Attach no further meaning to this number other than "the
> number of changes that have been made to the repository." That's all it
> is.<<<<<
>
> Good evening, Ryan.
>
> Yes, I understand that. But, if the current revision of the SRS is 4.3 (as
> recorded in the change log on the back page of the document), and someone
> comes to me and tells me that he needs revision 4.1 and wants to know how
> he can check it out, what do I tell him if the whole repository is at
> revision 17?
As others have noted this is a perfect example of tags. Think of the
workflow as the following.
1. People work no documents on trunk. They makes changes, commit them
for sharing amongst the team. These are draft changes.
2. The team decide the documents are at a point for 'publication'.
Copy the trunk to a tag and name it with the 'publication version
number'.
3. goto 1 and work towards the next publication.
Individual draft changes are identifiable via 'svn log' which will
list the revision number, log message and user. Published revisions
are explicitly versioned and are found in the tags folder (or whatever
you want to call it).
If the files were able to be merged (non-binary) then you could
actually branch from trunk and finalise the publication through
peer-review before actually publishing to a tag. There are a lot of
options here - subversion is quite flexible in nearly all respects
except for providing individual revision numbers for files.
> This is aside from the issue about if he wants the SRS he'll have to check
> out everything else in that repository directory including stuff he doesn't
> care about.
Not being able to check out individual files is a little inconvenient.
But don't interprete this as the need to check out the whole
repository, you can absolutely check out a given folder in the
repository so you can still partition documentation by subject,
project or whatever suits. I'd recommend that this be planned out a
little though since if you utilise tagging you'll probably want a tags
folder per subject/project.
> (I suggested that the only real "fix", in that case, would be to put each
> file into its own repository and I thought I was going to be lynched...) :-(
Please don't do that. I can't see this as even remotely a rational
solution. If nothing else, managing backups and repository
verification for dozens and dozens of microscopic repositories is far
from using time productively.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Problems with Limitations or "Differences" of Subversion
Posted by Les Mikesell <le...@gmail.com>.
On Tue, 2006-11-07 at 16:03, Gavin Lambert wrote:
> > He would checkout or switch to the 4.1 release tag which
> > would have a URL something like this:
> >
> > url://host/repos/project/tags/4.1
> >
> > He would not need to know a revision.
>
> Additionally, if he just wanted to look at the file (which makes sense
> as you can't commit unless you're at the HEAD anyway), then you can
> export the file instead of using checkout. IIRC, export works for
> individual files, not just folders.
If you just want to look at a file or grab a copy for some reason
other then editing, there is always the web interface when you
access via http/https, or you can use viewvc.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Problems with Limitations or "Differences" of Subversion
Posted by Gavin Lambert <ga...@compacsort.com>.
Quoth Mark Phippard <ma...@softlanding.com>:
> He would checkout or switch to the 4.1 release tag which
> would have a URL something like this:
>
> url://host/repos/project/tags/4.1
>
> He would not need to know a revision.
Additionally, if he just wanted to look at the file (which makes sense
as you can't commit unless you're at the HEAD anyway), then you can
export the file instead of using checkout. IIRC, export works for
individual files, not just folders.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Mark Phippard <ma...@softlanding.com>.
Eric <sp...@scoot.netis.com> wrote on 11/06/2006 10:12:56 PM:
> At 09:24 PM 11/6/2006, Ryan Schmidt wrote:
>
> <RS>>>>>Do not think of it as the version number (or more properly:
> revision number) *of a file* or *of a directory* but instead *of the
> repository*. Attach no further meaning to this number other than "the
> number of changes that have been made to the repository." That's all it
> is.<<<<<
>
> Good evening, Ryan.
>
> Yes, I understand that. But, if the current revision of the SRS is 4.3
(as
> recorded in the change log on the back page of the document), and
someone
> comes to me and tells me that he needs revision 4.1 and wants to know
how
> he can check it out, what do I tell him if the whole repository is at
> revision 17?
He would checkout or switch to the 4.1 release tag which would have a URL
something like this:
url://host/repos/project/tags/4.1
He would not need to know a revision.
> This is aside from the issue about if he wants the SRS he'll have to
check
> out everything else in that repository directory including stuff he
doesn't
> care about.
>
> (I suggested that the only real "fix", in that case, would be to put
each
> file into its own repository and I thought I was going to be lynched...)
:-(
The repository is a file system. You just need to organize the filesystem
in such a manner that intelligent subsets can be grabbed. Just think of
if you were storing your files in folders on a network share and you
wanted to organize it so that someone could grab a folder at various
levels of the share and that would get them what they need.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: Problems with Limitations or "Differences" of Subversion
Posted by Méresse Christophe <ch...@nagra.com>.
> Yes, I understand that. But, if the current revision of the
> SRS is 4.3 (as
> recorded in the change log on the back page of the document),
> and someone
> comes to me and tells me that he needs revision 4.1 and wants
> to know how
> he can check it out, what do I tell him if the whole repository is at
> revision 17?
Well, that's the same problem with CVS (your current revision of the SRS 4.1 will not correspond to the CVS file revision 1.1.1.12 for instance) or clearcase (1..2..3..4 etc..)
Why not just tagging your SRS:
svn copy //repos/<...>/SRS.pdf //repos/<...>/SRS_4.1.pdf (you do not even need to manage any trunk or tags directory...)
or
svn copy //repos/<...>/SRS.pdf //repos/<...>/archive/SRS_4.1.pdf (if you don't want to mess the current version with the archive ones...)
Christophe Méresse
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Eric <sp...@scoot.netis.com>.
At 09:24 PM 11/6/2006, Ryan Schmidt wrote:
<RS>>>>>Do not think of it as the version number (or more properly:
revision number) *of a file* or *of a directory* but instead *of the
repository*. Attach no further meaning to this number other than "the
number of changes that have been made to the repository." That's all it
is.<<<<<
Good evening, Ryan.
Yes, I understand that. But, if the current revision of the SRS is 4.3 (as
recorded in the change log on the back page of the document), and someone
comes to me and tells me that he needs revision 4.1 and wants to know how
he can check it out, what do I tell him if the whole repository is at
revision 17?
This is aside from the issue about if he wants the SRS he'll have to check
out everything else in that repository directory including stuff he doesn't
care about.
(I suggested that the only real "fix", in that case, would be to put each
file into its own repository and I thought I was going to be lynched...) :-(
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 6, 2006, at 19:35, Eric wrote:
> As we see it, the two main limitations of Subversion are the
> inability to check out and check in individual files (you have to
> do whole directories), and the fact that the version number for the
> whole repository increments whenever you make any change to any one
> file.
>
> I really can't defend the second issue .. it just seems to me like
> a wrong design decision and I can't think of a reason why it's good
> or why it happened.
[snip]
> If I make a change to the SRS, I don't want the SDD's version
> number to bump.
Do not think of it as the version number (or more properly: revision
number) *of a file* or *of a directory* but instead *of the
repository*. Attach no further meaning to this number other than "the
number of changes that have been made to the repository." That's all
it is.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Tuesday, November 07, 2006 3:35 PM -0600 Les Mikesell
<le...@gmail.com> wrote:
>> Twiki is likely good inside a LAN but I'd be uncomfortable with
>> deploying a public one.
>
> If we avoid everything that has ever had an exploit and has subsequently
> been fixed we wouldn't have much to work with, much less an OS to
> run it on.
True. At the time, Twiki had seemingly just become aware of the need for
security, and I felt it too "green" on that subject to use. (It was using
the backtick operator on unfiltered input!) Likely it's had some time to
season and is now much more robust. It's worth a second look.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Les Mikesell <le...@gmail.com>.
On Tue, 2006-11-07 at 11:44 -0800, Kenneth Porter wrote:
> > I've always liked twiki - and find it amusing that http://wiki.java.net
> > uses it (it's perl). The only problem I've had is that people like to
> > attach binaries that you can't easily view/edit directly over the web.
>
> At one time researching wikis I tried Twiki and shortly thereafter a major
> security issue was discovered and lots of public Twikis got exploited. I
> took down my Twiki and put my wiki research on the back burner, but stayed
> subscribed to their new security announcement list. I've seen a few more
> exploits discovered.
>
> Twiki is likely good inside a LAN but I'd be uncomfortable with deploying a
> public one.
If we avoid everything that has ever had an exploit and has subsequently
been fixed we wouldn't have much to work with, much less an OS to
run it on.
> I've got a Mediawiki deployed, and its high-profile use with Wikipedia
> would suggest it's more likely to be regularly attacked, and therefore
> likely to be more audited and hence more bullet-proof.
www.twiki.org has its own public site, and I'd think the wiki.java.net
example would get some public attention. But there are wikis for
every taste: http://www.wikimatrix.org/ has the feature lists.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Tuesday, November 07, 2006 1:32 PM -0600 Les Mikesell
<le...@gmail.com> wrote:
> I've always liked twiki - and find it amusing that http://wiki.java.net
> uses it (it's perl). The only problem I've had is that people like to
> attach binaries that you can't easily view/edit directly over the web.
At one time researching wikis I tried Twiki and shortly thereafter a major
security issue was discovered and lots of public Twikis got exploited. I
took down my Twiki and put my wiki research on the back burner, but stayed
subscribed to their new security announcement list. I've seen a few more
exploits discovered.
Twiki is likely good inside a LAN but I'd be uncomfortable with deploying a
public one.
I've got a Mediawiki deployed, and its high-profile use with Wikipedia
would suggest it's more likely to be regularly attacked, and therefore
likely to be more audited and hence more bullet-proof.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Les Mikesell <le...@gmail.com>.
On Tue, 2006-11-07 at 09:38 -0700, Mark wrote:
> I don't have one hosted on the internet you could look at. We use
> twiki, but I hate it. It uses rcs to version the content files.
> Mediawiki versions files, too. I think all wiki implementations do.
I've always liked twiki - and find it amusing that http://wiki.java.net
uses it (it's perl). The only problem I've had is that people like to
attach binaries that you can't easily view/edit directly over the web.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Mark <ma...@mitsein.net>.
I don't have one hosted on the internet you could look at. We use
twiki, but I hate it. It uses rcs to version the content files.
Mediawiki versions files, too. I think all wiki implementations do.
On 11/7/06, Eric <sp...@scoot.netis.com> wrote:
> At 01:05 AM 11/7/2006, Mark wrote:
>
> <M>>>>>For my team and many of the projects that we host, all of our code
> goes into subversion and all of our documentation goes into a wiki. It's
> easily viewable by anyone on any platform anywhere, it's version
> controlled, and it's easily manipulated.<<<<<
>
> Good morning, Mark.
>
> Can you elaborate on that a bit? I actually don't know much about wikis
> except as a user (mostly of Wikipedia). I wasn't aware they included
> version control.
>
> Which one would be the best for me to look into for installation on Linux?
>
> Are you hosting one that I could look at without violating anyone's
> nondisclosure or privacy rules?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Mark
"Blessed is he who finds happiness in his own foolishness, for he will
always be happy."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Problems with Limitations or "Differences" of Subversion
Posted by Garrett McGrath <gm...@Princeton.EDU>.
Trac can store them in a variety of ways including sqlite, postgres and
mysql (with 0.10.1). I believe it was first built on sqlite so that's the
best supported and it works pretty good. Makes backup a breeze as well
since it's stored in a file format in your trac 'enviroment' area. The
thing with trac is you actually get a button called 'browse source' that can
be linked to an svn repository, this isn't to store the wiki pages but
instead to view an actual code repository. The ticket system uses the sql
backend you select to store it's data as well. They've also implemented a
discussion board system (thru a plugin) that makes it a bit more extensible
to developers working in an entirely virtual enviroment.
-----Original Message-----
From: Kenneth Porter [mailto:shiva@sewingwitch.com]
Sent: Tuesday, November 07, 2006 1:51 PM
To: users@subversion.tigris.org
Cc: Eric
Subject: Re: Problems with Limitations or "Differences" of Subversion
--On Tuesday, November 07, 2006 10:56 AM -0500 Eric
<sp...@scoot.netis.com> wrote:
> Can you elaborate on that a bit? I actually don't know much about
> wikis except as a user (mostly of Wikipedia). I wasn't aware they
> included version control.
>
> Which one would be the best for me to look into for installation on Linux?
More generally, you probably want a "content management system" (CMS), of
which wikis are members. Two I've seen recommended are Mediawiki (used by
Wikipedia) and Drupal.
A CMS is an online documentation system, and a wiki is a version-controlled
CMS. Different wikis store the versioning in different ways. Mediawiki
stores the revisions in a database (eg. MySQL). Twiki stores revisions in
RCS files. I'd guess that Trac stores revisions in Subversion.
A common problem with public wikis is defacement (including spam). The
versioning means that you can remove the defacement by reverting to an
earlier revision.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Tuesday, November 07, 2006 10:56 AM -0500 Eric
<sp...@scoot.netis.com> wrote:
> Can you elaborate on that a bit? I actually don't know much about wikis
> except as a user (mostly of Wikipedia). I wasn't aware they included
> version control.
>
> Which one would be the best for me to look into for installation on Linux?
More generally, you probably want a "content management system" (CMS), of
which wikis are members. Two I've seen recommended are Mediawiki (used by
Wikipedia) and Drupal.
A CMS is an online documentation system, and a wiki is a version-controlled
CMS. Different wikis store the versioning in different ways. Mediawiki
stores the revisions in a database (eg. MySQL). Twiki stores revisions in
RCS files. I'd guess that Trac stores revisions in Subversion.
A common problem with public wikis is defacement (including spam). The
versioning means that you can remove the defacement by reverting to an
earlier revision.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Eric <sp...@scoot.netis.com>.
At 01:05 AM 11/7/2006, Mark wrote:
<M>>>>>For my team and many of the projects that we host, all of our code
goes into subversion and all of our documentation goes into a wiki. It's
easily viewable by anyone on any platform anywhere, it's version
controlled, and it's easily manipulated.<<<<<
Good morning, Mark.
Can you elaborate on that a bit? I actually don't know much about wikis
except as a user (mostly of Wikipedia). I wasn't aware they included
version control.
Which one would be the best for me to look into for installation on Linux?
Are you hosting one that I could look at without violating anyone's
nondisclosure or privacy rules?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Problems with Limitations or "Differences" of Subversion
Posted by Mark <ma...@mitsein.net>.
Personally, I think subversion makes a great code repository and a
lousy document repository.
One reason is the one that doesn't make sense to you: repository
versioning. For a code project, it makes total sense since the
repository exists as a whole. One file doesn't mean squat, but put
all the files in the repository together and they make an application
that does stuff. That isn't true for a document repository.
<generalization>Another factor is that people doing documentation just
don't care about subversion or revision control.</generalization>
The other factor is that the documents you are storing are likely
binary (MS Office, PDF, Framemaker, or something). So your repository
will grow pretty fast with each revision.
For my team and many of the projects that we host, all of our code
goes into subversion and all of our documentation goes into a wiki.
It's easily viewable by anyone on any platform anywhere, it's version
controlled, and it's easily manipulated.
On 11/6/06, Eric <sp...@scoot.netis.com> wrote:
>
> I had a rather, uh, spirited discussion with one of my business partners
> today about version control systems in general and Subversion in particular.
>
> We have more or less settled on Subversion to handle version control for
> all of our documents ... company policy / procedure documents, meeting
> agendas and minutes, project specifications, that sort of thing ... in
> addition to source code for projects.
>
> And, therein lies at least part of the problem ... there are two aspects of
> Subversion's operation that are causing us many problems ... one of which I
> can live with (and defend the operation of Subversion in the face of
> arguments from my partners) and the other of which I'm not sure that I can.
>
> As we see it, the two main limitations of Subversion are the inability to
> check out and check in individual files (you have to do whole directories),
> and the fact that the version number for the whole repository increments
> whenever you make any change to any one file.
>
> I really can't defend the second issue .. it just seems to me like a wrong
> design decision and I can't think of a reason why it's good or why it happened.
>
> But, as for the first, I got to thinking after my partner left to go home
> ... If you consider that Subversion is primarily for source code control,
> then I guess it makes sense to force the checking out of a whole directory
> rather than a single file. After all, if you follow the rule that your
> code should at least build before you check it in, how can you build it if
> you don't have all the rest of the files?
>
> There is a school of thought that says that it is A Very Bad Idea for
> programmers to keep local copies of files (after all, what the %%#$ is
> version control for??) and that they should, I suppose, strip off all old
> copies of the source every time they check something in. I don't buy into
> that and it seems the designers of Subversion didn't either ... you keep a
> local work copy of the source files, and you update them whenever necessary
> with the latest versions from the version-controlled source tree, right?
>
> That works OK for source file sets where each file is related to the
> rest. It works a LOT less well in the case of directory trees full of
> documents that are related to one another only because they're part of the
> same project or part of the collection of policies and procedures for the
> same company. If I make a change to the SRS, I don't want the SDD's
> version number to bump.
>
> I'm beginning to think we'd be better off using Subversion for source code
> control and something else for document control, though it seems
> unfortunate that we would have to do that and not use the same tool for both.
>
> How do you all handle this within your companies or projects?
>
> Eric
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Mark
"Blessed is he who finds happiness in his own foolishness, for he will
always be happy."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org