Re: Developers: Bazaar branches

[JMGross]

Has anyone thought of using SubVersion?
It offers cheap branches, a nice and easy-to-use UI under Windows (TortoiseSVN) und much more.
The UI can handle file-based repositories on local/network drives as well as through URL.
I use it for several years now for all of our projects and it never let me down.

JMGross

----- Ursprüngliche Nachricht -----
Von: Dmitry Zuikov
An: GCC for MSP430 - http://mspgcc.sf.net
Gesendet am: 10 Sep 2009 05:31:01
Betreff: Re: [Mspgcc-users] Developers: Bazaar branches


> > And just for notice. We have used bazaar for the couple of years, but
> >  now we use git for all out projects, because of it's speed and cheap
> >  branches feature.
>
> shouldn't branches also be cheap with bzr's shared repositories?

As far as I remember, branch in bazaar is just a full copy of
repository, so branches are using not so often like in git.

git also has much more additional tools, including GUI - like gitk.
But in the same time git has problems with Windows. But we have
problems with bazaar when used UTF-8 comments in russian  --- it made
the python to produce some exception and the whole repository became
inaccessible on Windows.  It's just for sharing the experience, not
for arguing.

> unfortunately you can't make everyone happy by choosing one of the
> popular DVCS :/

Yep, anyway bzr is much better than cvs, and it's easy to migrate the
project from bzr to git with all history in any time.


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Grant Edwards-6]

On 2009-09-28, JMGross <mspgcc@...> wrote:
>
>
> Has anyone thought of using SubVersion?

I imagine they have.  It's not really "distributed" the way the
systems under discussion are.  SVN still uses a single central
repository that everybody must have fairly constant access to.

--
Grant


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Dmitry Zuikov]

> Has anyone thought of using SubVersion?
> It offers cheap branches, a nice and easy-to-use UI under Windows (TortoiseSVN) und much more.

Yes of course. It's so old. And so slow. It needs a server...

---
Regards,
Dmitry


> ----- Ursprüngliche Nachricht -----
Von: Dmitry Zuikov

> An: GCC for MSP430 - http://mspgcc.sf.net
> Gesendet am: 10 Sep 2009 05:31:01
> Betreff: Re: [Mspgcc-users] Developers: Bazaar branches
>
>
> > > And just for notice. We have used bazaar for the couple of years, but
> > >  now we use git for all out projects, because of it's speed and cheap
> > >  branches feature.
> >
> > shouldn't branches also be cheap with bzr's shared repositories?
>
> As far as I remember, branch in bazaar is just a full copy of
> repository, so branches are using not so often like in git.
>
> git also has much more additional tools, including GUI - like gitk.
> But in the same time git has problems with Windows. But we have
> problems with bazaar when used UTF-8 comments in russian  --- it made
> the python to produce some exception and the whole repository became
> inaccessible on Windows.  It's just for sharing the experience, not
> for arguing.
>
> > unfortunately you can't make everyone happy by choosing one of the
> > popular DVCS :/
>
> Yep, anyway bzr is much better than cvs, and it's easy to migrate the
> project from bzr to git with all history in any time.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@...
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[JMGross]

Well, 'old' is no criteria. The GCC version used for mspgcc is pretty old yet it does its job. Same for most everything else (including ourselves :) )
Where so you set a mark when something is too old to be used (even if still under development)? 1 day? 1 week? 1 month? 1 year? Als long as it does the job, fine, And if not, it might be a young as can be and still
useless.
'Slow' is relative. I can't really compare. The slowest thing here is our server (which has been really misconfigured by generations of admins). So I cannot determine if the (normally barely noticeable) delays are caused by
SVN or by the server file access itself.
And for the need of a server, well, yes, sure. Every repository needs to be stored somewhere. Without access to the storage place I cannot access the repository. No matter whether it is a dedicated server, some
webspace somewhere or a mesh cloud.

But it was just an idea. With everything else I looked upon (quick glances only, admitted) it seemed to me I'd be more busy handling the repository than working with the project. When choosing my tools, my top citeria
is always usability (and maybe price, which had lead me originally to mspgcc).

JMGross


----- Ursprüngliche Nachricht -----
Von: Dmitry Zuikov
An: mspgcc-users@...
Gesendet am: 28.September.2009 17:59:15
Betreff: Re: [Mspgcc-users] Developers: Bazaar branches

> Has anyone thought of using SubVersion?
> It offers cheap branches, a nice and easy-to-use UI under Windows (TortoiseSVN) und much more.

Yes of course. It's so old. And so slow. It needs a server...



------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Grant Edwards-6]

On 2009-09-28, JMGross <mspgcc@...> wrote:

> And for the need of a server, well, yes, sure. Every
> repository needs to be stored somewhere.

No, not really.

> Without access to the storage place I cannot access the
> repository. No matter whether it is a dedicated server, some
> webspace somewhere or a mesh cloud.

Some other revision control systems don't rely on a single,
central server the way RCS, CVS, SVN do.  Such systems are
usually referred to as "distributed" revision control systems.
Most open-source development projects tend to be moving away
from the single-central-server model to the more distributed
model.

  http://en.wikipedia.org/wiki/Distributed_revision_control

--
Grant

 


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Dmitry Zuikov]

> And for the need of a server, well, yes, sure. Every repository needs to be stored somewhere. Without access to the storage place I cannot access the repository. No matter whether it is a dedicated server, some
> webspace somewhere or a mesh cloud.

> But it was just an idea. With everything else I looked upon (quick glances only, admitted) it seemed to me I'd be
>
> more busy handling the repository than working with the project. When choosing my tools, my top citeria
> is always usability (and maybe price, which had lead me originally to mspgcc).

Well, regarding to my opinion, DVCS are more easy to setup and use. In
fact, they do not need any setup at all. Basically, all what you need to
share a repository with DVCS, it's to create a directory on a server and
assign the user/group. Comparing to SVN it's almost no-brainer.

>From the point of ease of use, the champion, probably is Mercurial (hg).
But on my opinion, it's better to make an effort and learn the git. It's
probably most powerful DVCS on the moment.

It's just my opinion, nothing  more. I've been using the bazaar for some
years, but I switched to git a half of year ago and I'm very impressed
of it.


---
Regards,
Dmitry





------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[JMGross]

Grant:

That's what I meant with a 'mesh cloud'. It still needs to be stored somewhere. On a single place (that is hopefully available) or on every single system in a copy, constantly updating with the others (who are hopefully
online and have a recent version available). If it's not stored somewhere, it is not available, no matter which type of distribution is used.
In my opinion, a dedicated server (with some backups) is by far better than a repository that is or is not available and is or is not up to date.
The fact that TortoiseSVN (and I guesst SVN itself does so too) keeps a working base together with the (actually altered) working copy makes it a somewhat distributed repository too, as every user has a certain
repository revision (not necessary the newes, depending on the latest update) on its computer and can make DIFF or revert operations without any connection to the repository.
Unfortunately there is no Linux version of Tortoise (only for SVN itself), but since both are compatible and linux users (at least the programmers) are usually fond of console usage... :)

Dmitry:
Well, that's exactly what I do with TortoiseSvn: create a directory on a server. That's all. Tortoise is linked against SVN and uses its core engines, but that does not mean that it requires an SVN server or such.
Everything is built-in to do the job on its own. Transparently.
When working locally (or with a mapped network drive), simply right-click onto an empty folder and say 'create repository'. Then right-click again and check files in or out.
It also works with URLs instead of local drives (which of course is more important for open source projects).
You can use a Berkeley database server if available for the repositories, but simple file access is sufficient. Can't be easier. Even our DAUs in the production learned to use it, for getting the latest production
snapshots, in a few minutes.

JMGross

----- Ursprüngliche Nachricht -----
Von: Grant Edwards
An: mspgcc-users@...
Gesendet am: 28 Sep 2009 18:51:18
Betreff: Re: [Mspgcc-users] Developers: Bazaar branches

On 2009-09-28, JMGross <mspgcc@...> wrote:

> And for the need of a server, well, yes, sure. Every
> repository needs to be stored somewhere.

No, not really.

> Without access to the storage place I cannot access the
> repository. No matter whether it is a dedicated server, some
> webspace somewhere or a mesh cloud.

Some other revision control systems don't rely on a single,
central server the way RCS, CVS, SVN do.  Such systems are
usually referred to as "distributed" revision control systems.
Most open-source development projects tend to be moving away
from the single-central-server model to the more distributed
model.

  http://en.wikipedia.org/wiki/Distributed_revision_control




----- Ursprüngliche Nachricht -----
Von: Dmitry Zuikov
An: mspgcc-users@...
Gesendet am: 28 Sep 2009 18:56:36
Betreff: Re: [Mspgcc-users] Developers: Bazaar branches

> And for the need of a server, well, yes, sure. Every repository needs to be stored somewhere. Without access to the storage place I cannot access the repository. No matter whether it is a dedicated
server, some
> webspace somewhere or a mesh cloud.

> But it was just an idea. With everything else I looked upon (quick glances only, admitted) it seemed to me I'd be
>
> more busy handling the repository than working with the project. When choosing my tools, my top citeria
> is always usability (and maybe price, which had lead me originally to mspgcc).

Well, regarding to my opinion, DVCS are more easy to setup and use. In
fact, they do not need any setup at all. Basically, all what you need to
share a repository with DVCS, it's to create a directory on a server and
assign the user/group. Comparing to SVN it's almost no-brainer.


 


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Grant Edwards-6]

On 2009-09-29, JMGross <mspgcc@...> wrote:

> That's what I meant with a 'mesh cloud'. It still needs to be
> stored somewhere. On a single place (that is hopefully
> available) or on every single system in a copy, constantly
> updating with the others (who are hopefully online and have a
> recent version available).

Except that's not how a distributed control system works.  It's
not the case where there are mutliple mirrored copies of a
single repository.  SVN uses a single repository on a single
server, and there is no mechanism to allow the repository
stored in multiple places.

> If it's not stored somewhere, it is not available, no matter
> which type of distribution is used. In my opinion, a dedicated
> server (with some backups) is by far better than a repository
> that is or is not available and is or is not up to date.

I don't think you understand how distributed version control
systems work.  It's not the same as having "a repository"
that's stored in the cloud.

> The fact that TortoiseSVN (and I guesst SVN itself does so
> too) keeps a working base together with the (actually altered)
> working copy makes it a somewhat distributed repository too,

Yup, that's how SVN works. You can do a diff/revert using just
the local copy but most all of the other operations still
require a live connection to the server.  DVCS systems don't.

> as every user has a certain repository revision (not necessary
> the newes, depending on the latest update) on its computer and
> can make DIFF or revert operations without any connection to
> the repository.

True.

> Unfortunately there is no Linux version of Tortoise (only for
> SVN itself), but since both are compatible and linux users (at
> least the programmers) are usually fond of console usage... :)

Tortoise doesn't really have anything to do with how SVN works,
so it doesn't matter whether or not there's a Linux version.
The local snapshot is characteristic of the underlying SVN
system.  There are plenty of other GUI interfaces to SVN, but
there are still fundamental differences in the way than a
single-reposity system works and the way that a distributed
system works.

--
Grant


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[JMGross]

Well this goes much too far, so this will be my last reply as this is going to be as off-topic as I can think of :)


----- Ursprüngliche Nachricht -----
Von: Grant Edwards
Gesendet am: 29 Sep 2009 19:16:18

On 2009-09-29, JMGross <mspgcc@...> wrote:

>> That's what I meant with a 'mesh cloud'. It still needs to be
>> stored somewhere. On a single place (that is hopefully
>> available) or on every single system in a copy, constantly
>> updating with the others (who are hopefully online and have a
>> recent version available).

>Except that's not how a distributed control system works.  It's
>not the case where there are mutliple mirrored copies of a
>single repository.  SVN uses a single repository on a single
>server, and there is no mechanism to allow the repository
>stored in multiple places.

No, everybody has a piece of the repository, or not, and you must be lucky to have at least someone online who has the piece you need. You cannot ever be sure that you'll get the latest revision (the two people with
the latest are just offline) and you'll never notice.
It works better with an increasing base of users but there remains a statistical uncertainity.
The main problem is the same: if the information is not available, it is not available. With a dedicated server, no information or all is available, on a distributed system more or less is available (from nothing to all) and
you'll never really know how much, unless there is again a central point where at least the metainformation is gathered.

>> If it's not stored somewhere, it is not available, no matter
>> which type of distribution is used. In my opinion, a dedicated
>> server (with some backups) is by far better than a repository
>> that is or is not available and is or is not up to date.

>I don't think you understand how distributed version control
>systems work.  It's not the same as having "a repository"
>that's stored in the cloud.

There are several different approaches. From a distributed repository (similar to the torrent DHC mechanism)  to a emule-like search in the cloud for the latest changes (with the same uncertainity).
I admittedly don't know how GIT or Bazaar exactly work, but as someone very clever once noticed: you cannot put more than a bit into a bit.
And even the mentioned wikipedia article (which does not tell much about the concepts) has in the 'disadvantages' section some points which are of big importance (even if desperately hidden between many
'companies fear' and other pseudo-disadvantages)

>> The fact that TortoiseSVN (and I guesst SVN itself does so
>> too) keeps a working base together with the (actually altered)
>> working copy makes it a somewhat distributed repository too,

>Yup, that's how SVN works. You can do a diff/revert using just
>the local copy but most all of the other operations still
>require a live connection to the server.  DVCS systems don't.

So you want to tell me that I can revert to a previous version or compare two random versions of a file without either having all the history stored locally or a network connection? Well, fine piece of Magic. Information
out of nowhere. If this is possible, I wonder why there are still programmers needed? It's all there, out of the void.

Each time, someone tells me he has developed a perpetuum mobile, a motor that requires less energy input as it outputs, or that he has pulled himself out of a swamp by its own hairs, I feel a strong urge do disbelief
him.

So unless someone can tell me how this shall work (and not just that it works and I have to believe it), all types of DVCS I can imagine have as many drawbacks as they might have advantages.

>> Unfortunately there is no Linux version of Tortoise (only for
>> SVN itself), but since both are compatible and linux users (at
>> least the programmers) are usually fond of console usage... :)

>Tortoise doesn't really have anything to do with how SVN works,

And was just mentioned as an example of ease of use.
I already stated that it is linked together with SVN and of course is the repository job done by SVN.
But it makes version control as easy as right-clicking the mouse in the windows explorer (or any other app that uses the explorer view)

> There are plenty of other GUI interfaces to SVN, but
> there are still fundamental differences in the way than a
> single-reposity system works and the way that a distributed
> system works.

I never questioned that.
But I questioned that a DVCS system MUST be better than SVN (or other server-based systems like Perforce, which I also used many years ago or CVS which I refused to use even more years ago) just because it is
a newer technology or more cool or whatever.
Both may have their strengths and both definitely have their drawbacks.
It depends on what you want to do with it and what features you need and what drawbacks you cannot afford.

JMGross


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

[Mario Palomo-2]

JMGross wrote:

>
> I never questioned that.
> But I questioned that a DVCS system MUST be better than SVN (or other server-based systems like Perforce, which I also used many years ago or CVS which I refused to use even more years ago) just because it is
> a newer technology or more cool or whatever.
> Both may have their strengths and both definitely have their drawbacks.
> It depends on what you want to do with it and what features you need and what drawbacks you cannot afford.
>
> JMGross
>
>

I think a DVCS is better than SVN (or any not-distributed-VCS), because with a
DVCS you can work easily using a centralized paradigm if you want, (ex: using a
canonical repository). With SVN (only centralized) you only can work with a
centralized paradigm: is less flexible. With Git, Mercurial and Bazaar you can
do and work (if you want) the same as with Subversion, but the inverse is not
possible.


Mario


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@...
https://lists.sourceforge.net/lists/listinfo/mspgcc-users