[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: GUI Notes

From: Alexander Mueller <alex_at_littleblue.de>
Date: 2001-07-16 08:53:27 CEST

Brian Behlendorf schrieb:

> On Fri, 13 Jul 2001, Alexander Mueller wrote:
> > > The thing that complicates it is merging in changes when your local repos
> > > has a conflicting local change;
> >
> > One could tell it not to change anything that has been changed locally
> >
> > > you might not want to do that
> > > "immediately", but as part of a batch process - and you might not want to
> > > automatically update non-conflicting deltas before you're ready to do the
> > > merge of the conflicting deltas, as that would leave the local copy
> > > potentially in an inconsistant state. Not to mention more major changes
> > > such as file or directory renames/deletes. It seems to me you want to
> > > poll to find when an update is needed on a frequent basis, and you might
> > > want to know which files have new versions available, but not necessarily
> > > transfer and merge the deltas until you're ready to do it as a batch.
> >
> > For the parts of code i am working on you are right. I just want to see what goes
> > on in the repository. But there are a lot of other directories I am not working on
> > and where I want to see updates immediately.
>
> There may be cross-dependencies, though, which would mean your VC tool
> would need to know about dependencies, or you'd have to deal with the fact
> that stuff would not compile at random times, an event that could have
> been caused by your programming work, or by a background update. If
> updates are an explicit action, and if the compile breaks after doing an
> update, you know where the problem is.

Probably you're right. But what do you think about a couple of switches built into
the GUI app. First of the options: do I want to have the automatic update feature at all?
Second option as a setting for each module. Third option as an exclusion on a dir base.

>
>
> > One example: all of our companies documents are revision controlled as well.
> > Its a module I am working on maybe once a week. Three or four people are commiting
> > to this module. I could do an update manually every time I am in there. But hey, my
> > CVS GUI is running all of the time, it could take over this job for me. Several errors
> > occured because I forgot to update and realize that there was a newer revision of
> > a file in the repository.
>
> If the UI *visualized* for you the files that have an update available,
> but didn't actually update them until you told it to, then it wouldn't be
> a problem.

Thats true. If my today WinCVS had this option probably I wouldnt request for
the automatic update feature. But with a totally new app why not integrate additional
options. As long as you can turn it on and off maybe even on a directory or file basis I
dont see a problem either.

>
>
> > I totally agree with you, but there is a lot of fine GPL software out
> > there we might want to use.
>
> And a lot that could stand a clean rewrite...
>
> > One day there will be a person out there to explain some specific GPL
> > questions to me... Like: Linux and loads of tools included in
> > distributions are GPLed. But RedHat is selling some packages for
> > $2,000 (in Germany). But if its GPL isnt RedHat enforced to make it at
> > least downloadable for free, so what you are buying is just some
> > expensive cd set? Like: Caldera goes even further to restrict the use
> > on a per-user based license. I dont have a problem with all of this, I
> > am just wondering. But probably this isnt the right place to discuss
> > question like these....
>
> Read the GPL, it's not that long. It'll answer your questions.
> Basically, what you're paying for above is support, as well as any
> commercial apps that aren't affected by the GPL on the other parts of the
> distribution.
>
> Brian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:33 2006

This is an archived mail posted to the Subversion Dev mailing list.