"Offline files" and Linux

Gordon · External Since: Aug 01, 2005 Posts: 465

My setup is currently as follows:
Desktop, on which all my documents reside (for ease of backup)
I frequently work from my laptop which is connected wirelessly, using
Windows XP Offline files, where the laptop "caches" a copy of the files on
the local HDD for working when the desktop is unavailable. The system
automatically synchronises the two (both ways) when both machines are
connected and switched on.

My question is this - If I replaced the XP system on the desktop with a
flovour of Linux, would the laptop, still running XP, be able to take
advantage of Offline files, or is there a similar function in Linux?

Hope that's clear!

Thanks

Van Helsing · External Since: Jul 10, 2007 Posts: 3

Gordon wrote:

>
> My question is this - If I replaced the XP system on the desktop with a
> flovour of Linux, would the laptop, still running XP, be able to take
> advantage of Offline files, or is there a similar function in Linux?
>
If you install samba on the workstation and setup a share visible to the
laptop windows offline synch will work quite happily.

Linux has a many tools that do similar things, rsync and unison are just
a couple.

VH.

Andrzej Adam Filip · External Since: Sep 01, 2006 Posts: 19

Gordon <gbplinux.TakeThisOut@gmail.com.invalid> writes:

> My setup is currently as follows:
> Desktop, on which all my documents reside (for ease of backup)
> I frequently work from my laptop which is connected wirelessly, using
> Windows XP Offline files, where the laptop "caches" a copy of the files on
> the local HDD for working when the desktop is unavailable. The system
> automatically synchronises the two (both ways) when both machines are
> connected and switched on.
>
> My question is this - If I replaced the XP system on the desktop with a
> flovour of Linux, would the laptop, still running XP, be able to take
> advantage of Offline files, or is there a similar function in Linux?
>
> Hope that's clear!

Have you considered using "full blown" version control system on Linux?
[ e.g. CVS ]

P.S. CVS does not work well with *binary* files loved by MS.

--
[pl>en: Andrew] Andrzej Adam Filip : anfi.TakeThisOut@priv.onet.pl : anfi.TakeThisOut@xl.wp.pl
I wasn't kissing her, I was whispering in her mouth.
-- Chico Marx

Van Helsing · External Since: Jul 10, 2007 Posts: 3

Andrzej Adam Filip wrote:
> Gordon <gbplinux RemoveThis @gmail.com.invalid> writes:
>
>> My setup is currently as follows:
>> Desktop, on which all my documents reside (for ease of backup)
>> I frequently work from my laptop which is connected wirelessly, using
>> Windows XP Offline files, where the laptop "caches" a copy of the files on
>> the local HDD for working when the desktop is unavailable. The system
>> automatically synchronises the two (both ways) when both machines are
>> connected and switched on.
>>
>> My question is this - If I replaced the XP system on the desktop with a
>> flovour of Linux, would the laptop, still running XP, be able to take
>> advantage of Offline files, or is there a similar function in Linux?
>>
>> Hope that's clear!
>
> Have you considered using "full blown" version control system on Linux?
> [ e.g. CVS ]
>
> P.S. CVS does not work well with *binary* files loved by MS.
>
if you are going to do that may I suggest subversion - has a reasonable
windows gui (tortoise svn) and is quite happy with binaries

VH

Tim Southerwood · External Since: Apr 23, 2007 Posts: 113

Andrzej Adam Filip wrote:

> P.S. CVS does not work well with *binary* files loved by MS.
>

But Subversion does, and is pretty much a drop in replacement for CVS,
especially if starting anew.

Smile

Tim

gordon · External Since: Aug 08, 2005 Posts: 75

On Tue, 10 Jul 2007 12:42:28 +0000, Van Helsing wrote:

> If you install samba on the workstation and setup a share visible to the
> laptop windows offline synch will work quite happily.
>

Thanks for the info!

Andrzej Adam Filip · External Since: Sep 01, 2006 Posts: 19

Tim Southerwood <ts.TakeThisOut@dionic.net> writes:

> Andrzej Adam Filip wrote:
>
>> P.S. CVS does not work well with *binary* files loved by MS.
>>
>
> But Subversion does, and is pretty much a drop in replacement for CVS,
> especially if starting anew.
>
> Smile

Do you *play* stupid? Smile

I have written about keeping information about only *differences*
between versions. Keeping full binary files without any idea what have
changed between versions is a horrible waste of capabilities of any
version control system (IMHO).

*BUT* AFAIK MS "tools" can export files in text formats (e.g. XML)
better fitted for CVS.

--
[pl>en: Andrew] Andrzej Adam Filip : anfi.TakeThisOut@priv.onet.pl : anfi.TakeThisOut@xl.wp.pl
To avoid criticism, do nothing, say nothing, be nothing.
-- Elbert Hubbard

Tim Southerwood · External Since: Apr 23, 2007 Posts: 113

Andrzej Adam Filip wrote:

> Tim Southerwood <ts DeleteThis @dionic.net> writes:
>
>> Andrzej Adam Filip wrote:
>>
>>> P.S. CVS does not work well with *binary* files loved by MS.
>>>
>>
>> But Subversion does, and is pretty much a drop in replacement for CVS,
>> especially if starting anew.
>>
>> Smile

>
> Do you *play* stupid? Smile

> I have written about keeping information about only *differences*
> between versions. Keeping full binary files without any idea what have
> changed between versions is a horrible waste of capabilities of any
> version control system (IMHO).

Quote from the front page of the Subversion web site:

"# Efficient handling of binary files
Subversion is equally efficient on binary as on text files, because it uses
a binary diffing algorithm to transmit and store successive revisions."

There's not very much more you can do with an obscure binary blob, unless
the VCS understands its format.

Now sir, would you like your hat with or without gravy? ;->

> *BUT* AFAIK MS "tools" can export files in text formats (e.g. XML)
> better fitted for CVS.
>

I'm not sure that any of this is exactly what the OP wanted, but maybe he
does... My main point was, that IMHO, no-one should ever start using CVS,
not these days. Subversion is the neareast thing without the horrible edge
cases (like the binary files above, directory renames etc).

Mind you, if you heard Linus' talk at Google about Git, Subversion got
equally roasted...

Cheers

Tim

Van Helsing · External Since: Jul 10, 2007 Posts: 3

Tim Southerwood wrote:

>
> I'm not sure that any of this is exactly what the OP wanted, but maybe he
> does... My main point was, that IMHO, no-one should ever start using CVS,
> not these days. Subversion is the neareast thing without the horrible edge
> cases (like the binary files above, directory renames etc).
CVS is fine for a small local repository. I use it, together with a
custom perl script, for taking snapshots of system config files. It has
very low installation & usage overheads.
I also use svn, in its webdav incarnation for keeping files (mainly
non-text) in a central location for use on a variety of workstations,
Windows & Linux. Works ok but dealing with contentions can be a pain.

> Mind you, if you heard Linus' talk at Google about Git, Subversion got
> equally roasted...
Watched the video, and found it quite interesting. Not sure if Linus was
trying to be controversial for entertainment value or just has a grossly
over inflated opinion of himself. Git looks like a valuable tool (or it
will be when its finished) but it does seem very focussed on distributed
development rather than a version controlled repository of files. In
that sense SVN & Git are seeking to solve different, but related, problems.

VH.

Tim Southerwood · External Since: Apr 23, 2007 Posts: 113

Van Helsing wrote:

> Tim Southerwood wrote:
....
>> Mind you, if you heard Linus' talk at Google about Git, Subversion got
>> equally roasted...
> Watched the video, and found it quite interesting. Not sure if Linus was
> trying to be controversial for entertainment value or just has a grossly
> over inflated opinion of himself. Git looks like a valuable tool (or it
> will be when its finished) but it does seem very focussed on distributed
> development rather than a version controlled repository of files. In
> that sense SVN & Git are seeking to solve different, but related,
> problems.

I found his performance disappointing. Great man he is, but arrogance is
never becoming, even when played out as humour.

I did agree with his points in the context of the kernel; subversion would
be next to useless for that type of distributed development, but it is
excellent for centralised projects - however, it would have been gracious
to say something to that effect and then leave it alone.

Pity - I lost some respect for him after that...

Tim

Tony van der Hoff · External Since: Oct 15, 2005 Posts: 74

On 10 Jul at 17:24 Van Helsing <666.TakeThisOut@mail.inavlid> wrote in message
<BoOki.6746$oa7.903@newsfe1-gui.ntli.net>

> Tim Southerwood wrote:
[snip]
> > Mind you, if you heard Linus' talk at Google about Git, Subversion got
> > equally roasted...
> Watched the video, and found it quite interesting. Not sure if Linus was
> trying to be controversial for entertainment value or just has a grossly
> over inflated opinion of himself.

Link, please?

--
Tony van der Hoff | mailto:tony@vanderhoff.org
Buckinghamshire, England

Tim Southerwood · External Since: Apr 23, 2007 Posts: 113

Tony van der Hoff wrote:

> On 10 Jul at 17:24 Van Helsing <666 RemoveThis @mail.inavlid> wrote in message
> <BoOki.6746$oa7.903@newsfe1-gui.ntli.net>
>
>> Tim Southerwood wrote:
> [snip]
>> > Mind you, if you heard Linus' talk at Google about Git, Subversion got
>> > equally roasted...
>> Watched the video, and found it quite interesting. Not sure if Linus was
>> trying to be controversial for entertainment value or just has a grossly
>> over inflated opinion of himself.
>
> Link, please?
>
>

Sure:

http://www.youtube.com/watch?v=4XpnKHJAok8

Warning - it's a long talk (70 mins), so get a cuppa first.

Cheers

Tim

Tony van der Hoff · External Since: Oct 15, 2005 Posts: 74

On 10 Jul at 17:57 Tim Southerwood <ts.RemoveThis@dionic.net> wrote in message
<4693ba5e$0$641$5a6aecb4@news.aaisp.net.uk>

[snip]
>
> Sure:
>
> http://www.youtube.com/watch?v=4XpnKHJAok8
>
> Warning - it's a long talk (70 mins), so get a cuppa first.
>

Ta.

--
Tony van der Hoff | mailto:tony@vanderhoff.org
Buckinghamshire, England

Nick Leverton · External Since: Dec 24, 2004 Posts: 54

In article <BoOki.6746$oa7.903@newsfe1-gui.ntli.net>,
Van Helsing <666 RemoveThis @mail.inavlid> wrote:
>Tim Southerwood wrote:
>
>>
>> I'm not sure that any of this is exactly what the OP wanted, but maybe he
>> does... My main point was, that IMHO, no-one should ever start using CVS,
>> not these days. Subversion is the neareast thing without the horrible edge
>> cases (like the binary files above, directory renames etc).
>CVS is fine for a small local repository. I use it, together with a
>custom perl script, for taking snapshots of system config files. It has
>very low installation & usage overheads.
>I also use svn, in its webdav incarnation for keeping files (mainly
>non-text) in a central location for use on a variety of workstations,
>Windows & Linux. Works ok but dealing with contentions can be a pain.

I found svn very easy to get running if you use the flat file repository
layer. My colleague setup svn+ssh for remote access to the company's
system. It was very simple for me then to create a private svn server
on my own machine for my local work. You only need the complex svn
access stuff if your server has public style access. Compared to CVS
it is much easier with no messing around with CVS/ or locks.

Since then I've found svk to be a superb extension of svn. It uses
the svn syntax and Perl libraries to give you easy access to multiple remote
repositories - but that's not all.

Svk gives you local mirrors of remote repositories, synced revision
for revision. Great for laptop use. It also allows you to create local
repositories called depots. You check them out just as usual when you
are hacking on code. But in your working copy you can copy and patch and
merge between mirrors and depots. The WC shows you the base version for
each file, and you can keep track of your own branches and forks in as
many remote repositories as you like. Because the depots are just .svn
style repositories themselves underneath ~/.svk, you can even browse them
with a GUI tool if you want. Svk is a really great piece of software.

Nick
--
http://www.leverton.org/blosxom ... So express yourself

Tony Houghton · External Since: Jul 22, 2006 Posts: 88

In <f70m67$hdb$1@leverton.org>,
Nick Leverton <nick.TakeThisOut@leverton.org> wrote:

> I found svn very easy to get running if you use the flat file repository
> layer. My colleague setup svn+ssh for remote access to the company's
> system. It was very simple for me then to create a private svn server
> on my own machine for my local work. You only need the complex svn
> access stuff if your server has public style access. Compared to CVS
> it is much easier with no messing around with CVS/ or locks.

You can also use it over ssh without setting up a server. Very handy.

--
TH * http://www.realh.co.uk

Bruce Stephens · External Since: Aug 19, 2004 Posts: 179

Nick Leverton <nick.RemoveThis@leverton.org> writes:

[...]

> Compared to CVS it is much easier with no messing around with CVS/
> or locks.

For those that don't know, CVS uses lock files in its repository, and
every now and again something inevitably goes wrong and you get the
message "waiting for lock in directory ..." and things become wedged
because whatever was supposed to remove the lock didn't.

Subversion uses .svn rather than CVS, so the directories aren't so
visible. They're there, though, in every directory of your checkout.
They contain copies of the files as they were originally, so you can
do basic "svn diff" and "svn revert" locally. The bad news is that
the copies are at present uncompressed, so using subversion doubles
the size of a checkout. That might be an issue on a laptop---though
it might also be quite acceptable (it all depends).

In contrast, git, mercurial, monotone, svk require you to keep lots of
history (a whole repository) locally, but they all use good enough
compression that sometimes that takes less space than subversion's one
extra copy.

> Since then I've found svk to be a superb extension of svn. It uses
> the svn syntax and Perl libraries to give you easy access to multiple remote
> repositories - but that's not all.
>
> Svk gives you local mirrors of remote repositories, synced revision
> for revision. Great for laptop use. It also allows you to create local
> repositories called depots. You check them out just as usual when you
> are hacking on code. But in your working copy you can copy and patch and
> merge between mirrors and depots. The WC shows you the base version for
> each file, and you can keep track of your own branches and forks in as
> many remote repositories as you like. Because the depots are just .svn
> style repositories themselves underneath ~/.svk, you can even browse them
> with a GUI tool if you want. Svk is a really great piece of software.

Right, though when I used it (which *was* a while ago, so it may well
have got better since then) I managed a few times to screw something
or other up such that it was tricky to fix it (I committed to the
wrong place, or something). And while the local depot is a genuine
subversion repository (or multiple repositories), svk checkouts aren't
subversion checkouts, so most subversion-aware tools won't work on
them.

My guess is that if you're working with subversion repositories
(because your company uses subversion or something) then svk makes
lots of sense, but I don't think I'd recommend it otherwise. YMMV,
obviously.

Nix · External Since: Jul 29, 2004 Posts: 680

On 10 Jul 2007, Tim Southerwood outgrape:
[Linus's git talk]
> I found his performance disappointing. Great man he is, but arrogance is
> never becoming, even when played out as humour.

I don't think Linus was being especially arrongant in that talk. If you
don't know git, you might think that his comments regarding how it
knocks the socks off basically everything else were arrogant hyperbole:
but the thing is, those comments are *true*.

Subversion is left in the *dust* by git (and probably by bzr-ng and
other of the new breed of distributed VCSes, but I only really know git
of that group). I can't think of anything subversion does that git
doesn't do better, with the singular exception of acting like CVS. The
problem there is that most of what CVS does is totally broken by design
anyway, and anything emulating it will necessarily replicate a lot of
that brokenness: but if people are unwilling to retrain you might have
no choice.

(subversion also used to have much better docs and work on Windows.
Git has fixed the second; the first is improving fast but isn't quite
there yet.)

One trivial example of a useful thing git can do which is utterly
impossible in both Subversion and CVS: `git-blame' (the equivalent of
`cvs annotate' or `svn blame') with the -M option doesn't just tell you
what version each line was last changed in: it tells you *where those
lines came from* if they were moved from other files. This single
feature alone would be enough to make me migrate from other VCSes in an
instant, but there are similarly immense improvements in virtually every
other part of git, before you even get to the distributed-VCS part
(which Linus obviously thinks is central: given his focus, he would Smile

)

> I did agree with his points in the context of the kernel; subversion would
> be next to useless for that type of distributed development, but it is
> excellent for centralised projects - however, it would have been gracious
> to say something to that effect and then leave it alone.

The point here is simply this: why is any project `centralized'?
Ignoring things like single-company single-workplace development with
very limited disk space (in which case you can easily set $GIT_DIR and
ignore the distributed-development stuff) I can't see *any* circumstance
in which it makes sense to explicitly select a version control system
on the basis that it can't handle distribution. Why select a version
control system on the basis of features that it *lacks*?

Picking Subversion because its command-line interface and workflow is
similar to CVS's, *that's* understandable: git is quite different to use
and writing a porcelain that makes it work the same is incredibly
difficult. (The problem is, when someone else does something git can do
which CVS can't, how do you show this to the user? Branch merging, for
instance, is incessant in git, but CVS can't do it at all, and I've
encountered users who are confused at the very idea because CVS can't do
it...)

But I'd say `my users are CVS geeks who won't retrain' is the only real
reason to use Subversion anymore. I still have it on the system, but
just about the only thing that runs it is git-svn: I track remote
Subversion projects in git...

> Pity - I lost some respect for him after that...

Losing respect for people because they tell the unvarnished truth is
silly. Subversion was a worthy effort but it made the mistake of being
the first major free attempt at implementing something better than CVS,
so its authors were, um, stuck in a bit of a mental box. More recent
versoin control systems have broken well and truly out of that box,
but Subversion is still stuck in it.

Personally, I find using Subversion, let alone CVS, like being stuck in
jail. (At work we're using SCCS. *vomit* forget rename tracking, this
thing doesn't even know what directories are...)

--
`... in the sense that dragons logically follow evolution so they would
be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
furiously

Nix · External Since: Jul 29, 2004 Posts: 680

On 10 Jul 2007, Bruce Stephens told this:

> Nick Leverton <nick DeleteThis @leverton.org> writes:
>
> [...]
>
>> Compared to CVS it is much easier with no messing around with CVS/
>> or locks.
>
> For those that don't know, CVS uses lock files in its repository, and
> every now and again something inevitably goes wrong and you get the
> message "waiting for lock in directory ..." and things become wedged
> because whatever was supposed to remove the lock didn't.

It's worse than that. Tagging a directory in CVS requires taking a lock
out on the *whole directory*, which requires that nobody is committing
*or checking out* in that directory.

As a result, tagging in busy repos often took *ages*. IIRC before GCC
switched to Subversion it took upwards of a *day* to create each weekly
snapshot tag (ameliorated by a Cygnus/RH local patch that reduces the
scope of the locks CVS has to take out).

SVN is a huge improvement over CVS, oh yes.

> Subversion uses .svn rather than CVS, so the directories aren't so
> visible. They're there, though, in every directory of your checkout.
> They contain copies of the files as they were originally, so you can
> do basic "svn diff" and "svn revert" locally. The bad news is that
> the copies are at present uncompressed, so using subversion doubles
> the size of a checkout. That might be an issue on a laptop---though
> it might also be quite acceptable (it all depends).

This was a rather bad decision, I'd say.

> In contrast, git, mercurial, monotone, svk require you to keep lots of
> history (a whole repository) locally, but they all use good enough
> compression that sometimes that takes less space than subversion's one
> extra copy.

Indeed so. Some large examples.

The Linux kernel, all versions since 2.6.12rc2 (or something like that):

Packs: 253Mb in my tree
Checked-out copy: 285Mb

A really extreme example. GNU coreutils, *all* revisions since project
creation in 1992:

Packs: 48Mb
Checked-out copy: 8Mb

Yes, that's 40Mb extra, but that 40Mb took *fifteen years* to grow, and
in fact it's *shrinking* over time, not growing, because as git's
packing mechanism improves over time all you have to do is repack to
take advantage of it. (Faster-growing repositories like the Linux kernel
probably aren't shrinking over time, but still their size is
insignificant compared to the size of a modern disk.)

For projects you don't care about ancient history for there is `git
clone --depth <num>' to create a `shallow clone': but this has numerous
limitations and is best avoided unless you're short of disk space or on
a slow modem so you don't want to wait while a big initial clone comes
down.

svn is a real pig disk-space-wise. It's a bit of an indictment of their
codebase that they haven't even gzipped the bloody .text-base files even
though this was first proposed *five years* ago. How hard can it be to
stick something through zlib? The answer seems to be `if you're stuck in
the APR straitjacket, really hard'.

--
`... in the sense that dragons logically follow evolution so they would
be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
furiously

Bruce Stephens · External Since: Aug 19, 2004 Posts: 179

Nix <nix-razor-pit DeleteThis @esperi.org.uk> writes:

> On 10 Jul 2007, Bruce Stephens told this:

[...]

>> Subversion uses .svn rather than CVS, so the directories aren't so
>> visible. They're there, though, in every directory of your checkout.
>> They contain copies of the files as they were originally, so you can
>> do basic "svn diff" and "svn revert" locally. The bad news is that
>> the copies are at present uncompressed, so using subversion doubles
>> the size of a checkout. That might be an issue on a laptop---though
>> it might also be quite acceptable (it all depends).
>
> This was a rather bad decision, I'd say.

It's a perfectly reasonable "we can easily fix that later" sort of
decision.

It seems surprising that nobody's got around to it yet. On the other
hand, I guess it's probably not *that* much of an issue to most users,
so it never gets to the top of anyone's todo list.

From the outside, though, it looks plain daft: it means with
subversion (and this is an advance on CVS) you can do basic "svn diff"
and the like on that one revision without any network traffic. But
git (and others) can do arbitrary diffs and things over years of
history, quite often using less disk space than subversion.

And the compression doesn't slow things down. git's frighteningly
fast. (It felt pretty fast when I tried it on Windows, too. Not as
fast as Unix, obviously.)

[...]

> For projects you don't care about ancient history for there is `git
> clone --depth <num>' to create a `shallow clone': but this has
> numerous limitations and is best avoided unless you're short of disk
> space or on a slow modem so you don't want to wait while a big
> initial clone comes down.

If you've already got a local copy of something, it's possible to make
a further local copy while sharing the history, too. (Though for the
most part I'd guess it's not a big issue.)

> svn is a real pig disk-space-wise. It's a bit of an indictment of
> their codebase that they haven't even gzipped the bloody .text-base
> files even though this was first proposed *five years* ago. How hard
> can it be to stick something through zlib? The answer seems to be
> `if you're stuck in the APR straitjacket, really hard'.

I've seen some of the discussion about the issue, and yes, it does
appear that it's not quite as trivial is it feels it ought to be from
the outside. And (as I mention above) quite likely it's never quite
important enough to people already committed to using subversion (for
whatever reason)---disk space is cheap, after all, and an extra copy
of the source tends not to be significant relative to the cost of a
compiled tree. Still looks dumb if you're not using subversion,
though.

[...]

Tim Southerwood · External Since: Apr 23, 2007 Posts: 113

Nix coughed up some electrons that declared:

> On 10 Jul 2007, Tim Southerwood outgrape:
> [Linus's git talk]

<snip worthy advocation of git>

>> Pity - I lost some respect for him after that...
>
> Losing respect for people because they tell the unvarnished truth is
> silly. Subversion was a worthy effort but it made the mistake of being
> the first major free attempt at implementing something better than CVS,
> so its authors were, um, stuck in a bit of a mental box. More recent
> versoin control systems have broken well and truly out of that box,
> but Subversion is still stuck in it.
>
> Personally, I find using Subversion, let alone CVS, like being stuck in
> jail. (At work we're using SCCS. *vomit* forget rename tracking, this
> thing doesn't even know what directories are...)
>

That's all well and good. I didn't say git wasn't good. It looks very good
on the basis of the factual statements in Linus's presentation. However,
subversion, which is by your argument, a limited model, is perfectly good
for certain classes of jobs, especially those where there is a strong
concept of "the one true central copy" - eg I was using it for config file
control, so there was one true copy, a couple of test branches in the same
domain and it was there and working for us 4 years ago. And it was made
possible by people who gave their efforts away for free, and it is not
right to rubbish those people's efforts so lightly IMO.

There is a way to present the "truth" (which is subjective most of the time)
which persuades people your way is better, and there is a way to do it that
just pisses people off. You tend to get more milage with the former.

Tim